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齐 以 此 书 献 给 恩师 李 明 树 和 多 生 。 


为 什么 要 与 这 本 书 


真正 认真 开始 学 习 计算 机 是 在 2000 年 ， 当 时 书店 里 到 处 充斥 着 一 
系列 如 “21 天 精通 xxx”`“7 天 掌握 xxx" 之 类 的 图 书 ， 更 有 甚 者 宣称 “24 
小 时 学 会 xxx”。 既 是 高 科技 ， 又 这 么 容易 学 ， 谁 会 拒绝 呢 ? 于 是 我 走 
上 了 这 一 行 。 最 初 ， 确 实 如 这 些 书 所 说 ， 只 要 按照 书 中 描述 ， 将 类 似 
于 Visual Studio 等 IDE 安 六 到 机 器 上 ， 然 后 像 搭 积木 一 样 ， 拖 搜 儿 个 挥 
件 ， 再 添加 几 行 代码 ， 一 个 程序 就 完成 了 。 


短暂 的 兴奋 后 ， 好 奇 心 驱 使 我 想 更 深层 次 地 探索 这 一 切 是 如 何 发 
生 的 。 于 是 我 开始 关注 更 多 的 书籍 、 更 多 的 文章 、 更 多 的 编程 参考 ， 
国内 的 、 国 外 的 。 但 是 ， 结 果 计 我 很 泪 来 ， 如 果 依 然 是 用 积木 来 举例 
子 ， 我 发 现 它们 的 区 别 就 像 一 盒 10 块 的 积木 和 一 盒 100 块 的 积木 ， 只 
量 的 变化 ， 没 有 质 的 区 别 。 有 人 说 Win32 编 程 更 底层 ， 于 是 我 抛 开 
MEFC， 研 究 win32 编 程 。 但 是 ， 结 局 一 样 让 我 失望 。 其 实 它们 也 没有 
本 质 区 别 ， 只 不 过 如 果 把 MFC 比 作 大 块 积木 ，Win32 是 小 块 积木 而 
已 。 其 间 我 又 遍 寻 那些 Windows 内 幕 的 书 进行 研读 ， 也 是 猎 羽 而 归 ， 
似乎 前 方 已 无 路 可 走 .…… 


2003 年 4 月 毕业 后 ， 我 到 了 中 科 院 软件 所 工作 ， 开 始 从 事 与 Linux 
相关 的 开发 。 经 历 了 从 Windows 到 Linux 转 型 的 阵痛 后 ， 我 开始 喜欢 上 
了 Linux， 因 为 它 是 开源 的 ， 我 似乎 看 到 了 蜡 光 。 于 是 我 开始 疯狂 地 购 
天 Linux 方 面 各 种 各 样 的 书籍 ， 阅 读 各 种 权威 资料 ， 基 本 上 网 络 上 各 种 
权威 专家 推荐 的 书籍 在 我 的 书桌 上 全 部 可 以 找到 。 其 中 ， 绝 大 部 分 是 
关于 内 核 源 码 分 析 的 书 ， 于 是 我 一 头 扎 进 讲解 内 核 源 码 分 析 的 书 中 。 
但 是 我 很 快 淹没 在 庞大 的 内 核 代码 中 ， 几 次 都 到 了 难以 坚持 的 程度 ， 
但 是 我 强迫 自己 坚持 ， 强 制 自己 接受 作者 的 灌输 。 但 是 ， 最 终 的 结果 
是 : 看 的 时 候 似 乎 明白 ， 但 是 看 完 后 感觉 又 什么 也 没有 看 。 现 在 回头 
看 ， 当 初 很 有 点 像 * 育 人 摸 象 "这 个 典故 所 描述 的 ， 在 我 还 没有 看 清 整 
个 “大 象 的 时 候 ， 我 就 直接 去 研究 “大 象 ” 的 某 些 部 分 的 构造 了 。 


入 得 中 ， 我 又 看 到 了 另外 一 条 路 ， 低 版 本 的 内 核 。 我 就 像 一 个 在 
沙漠 中 饥 淘 难 忍 的 人 突然 看 到 了 绿洲 ， 我 甚至 将 低 版 本 的 内 核 打 印 出 
纸 版 ， 然 后 就 像 拿 着 伟人 语录 一 样 ， 只 要 疯 得 空 除 ， 就 度 诚 地 谱 心 研 
读 。 但 是 这 条 新 路 除了 代码 量 小 了 点 ， 与 之 前 的 相 比 并 没有 太 多 本 质 
的 区 别 ， 而 且 还 有 一 个 致命 的 缺点 一 一 早期 版 本 的 内 核 不 能 和 工作 中 
使 用 的 Linux 很 好 地 结合 。 


2005 年 ， 我 从 软件 所 被 派 到 了 中 科 红 底 。 最 初 从 事 保 面 操作 系统 
的 开发 ， 使 用 的 是 基于 Qt 的 KDE， 因 为 比较 成 熟 ， 所 以 当时 做 得 更 多 
的 是 一 些 维护 工作 。 但 是 在 我 的 探索 过 程 中 依然 重复 着 上 面 的 故事 ， 


没有 任何 的 起 色 。 转 折 大 概 出 现在 2007 年 ，Intel 因 为 一 个 低 功 耗 平台 
项 目 开始 和 中 科 红 弃 合 作 ， 他 们 要 在 低 功 耗 平台 上 开发 一 套 Linux 操 作 
系统 ， 我 接手 了 这 项 工作 。 因 为 这 个 平台 的 处 理 右 性 能 相对 要 低 ， 所 
以 对 于 操作 系统 的 和 要求 比较 高 。 同 时 因为 用 于 消费 类 电子 产品 ， 用 户 
体验 要 求 也 与 普通 的 PC 环境 完全 不 同 。 所 以 ， 基 于 已 有 的 桌面 系统 
乎 是 不 可 能 了 。 于 和 是， 我 们 开始 从 头 开 发 和 定制 。 


这 个 从 零 开始 的 过 程 ， 让 我 彻底 认识 了 整个 Linux 操 作 系 统 ， 而 不 
仅仅 是 Linux 的 内 核 。 曾 经 对 内 核 中 很 多 做 法 和 模块 不 明了 ， 通 过 构建 
整个 操作 系统 ， 我 欠 然 开朗 。 比 如 ， 内 核 中 的 DRM 模 块 ， 其 全 称 是 
Direct Rendering Manager， 从 字面 上 看 是 直接 泻 染 管 理 ， 这 到 底 是 什 

么 意思 ? 如 果 你 仅仅 从 内 核 的 角度 来 理解 ， 相 信 我 ， 你 永远 也 不 能 
确 理解 它 。 恰 恰 是 在 构建 系统 时 ， 亲 手 组 装 和 调试 图 形 环 境 ， 包 括 
X、OpenGL、2D/3D 图 形 张 动 ， 让 我 明白 了 DRM 的 用 途 。 这 样 的 例子 
举 不 胜 举 。 


经 过 这 个 过 程 中 ， 我 深刻 认识 到 ， 学 习 操作 系统 ， 有 三 件 最 重要 
的 事 : 第 一 是 实践 ， 第 二 依然 是 实践 ， 第 三 还 是 实践 。 老 祖宗 说 “ 纸 上 
得 来 终 觉 浅 "”， 唯 物 主义 者 说 “实践 是 检验 真理 的 唯一 标准 ”>， 两 句 话 中 
都 强 舍 着 同一 个 道理 一 一 追求 真理 离 不 开 实践 。 只 古 阅 读 、 分 析 源 码 
还 远 远 不 够 ,我 们 要 动手 实践 ， 从 实践 中 学 习 ， 实 践 反 过 来 再 促进 思 


考 。 而 且 ， 实 践 也 使 学 习 不 再 是 一 个 枯燥 乏味 的 负担 ， 而 是 一 个 乐 
趣 。 


通过 这 个 过 程 ， 我 也 体会 到 ， 即 使 只 为 了 学 习 内 核 ， 也 不 能 将 目 
光 全 部 放 在 内 核 上 。 从 整个 操作 系统 的 角度 ， 从 各 个 组 件 间 关系 的 角 
度 理解 内 核 ， 效 果 反 而 更 好 。 当 对 整个 系统 有 了 深入 的 理解 后 ， 再 去 
理解 组 成 操作 系统 的 各 个 组 件 ， 会 事半功倍 。 一 旦 从 总 体 上 理解 了 系 
统 ， 你 束 会 “ 艺 蜗 人 胆 大 ”， 束 可 以 尽情 地 “折腾 ”Linux 系 统 了 ， 因 为 每 
一 个 组 件 尽 在 你 的 掌握 之 中 。 而 恰恰 在 这 不 断 的 “折腾 ”中 ， 理 论 义 得 
到 不 断 的 提高 ， 从 此 进入 一 个 良性 循环 。 


很 早 我 束 想 把 这 种 方法 整理 成 书 ， 和 更 多 的 读者 分 享 ， 希望 帮助 
所 有 有 志 于 操作 系统 、 又 尚 在 门 外 徘 徊 的 年 轻 人 人 少 走 些 弯路 。 但 是 因 
为 忙于 生计 ， 只 能 在 有 限 的 业余 时 间 写 作 ， 所 以 直到 2013 年 中 期 ， 才 
基本 把 整个 书稿 写 完 。 


对 于 计算 机 而 言 ， 操 作 系统 的 重要 性 不 言 而 喻 ， 但 它 也 是 我 们 心 
中 的 痛 ， 我 将 为 此 求索 一 生 。 如 采 有 生 之 年 没 能 成 功 ， 请 将 我 埋 在 后 
来 者 脚下 。 


读者 对 象 


对 于 如 同 笔者 一 样 怀 撕 操作 系统 梦 的 爱好 者 ， 布 望 本 书 能 帮 他 们 
顺利 地 迈进 操作 系统 这 局 门 ， 对 于 正在 或 者 准备 学 习 操 作 系统 理论 的 
大 学 生 ， 本 书 将 帮助 他 们 感性 地 触摸 那些 “高 居 庙 特 之 上 ”的 抽象 理 
论 ; 对 于 高 级 读者 ， 本 书 中 的 很 多 内 容 对 他 们 也 很 有 用 处 ， 比 如 动态 
链接 部 分 的 讨论 、Linux 图 形 原理 部 分 的 讨论 等 。 


除了 以 上 的 读者 外 ， 本 书 适 合 以 下 相关 从 业 人 员 阅 读 : 


多 系统 程序 员 。 要 想 成 为 一 个 合格 的 系统 程序 员 ， 操 作 系统 和 编 
译 链接 技术 是 必 不 可 少 的 技能 ， 本 书 对 此 有 较 深 入 的 讨论 。 


令 腾 入 式 Linux 工 程 师 。 作 为 一 名 散 入 式 Linux 工 程 师 ， 应 该 知道 
如 何 使 用 交叉 编译 工具 链 、 配 置 编译 内 核 、 裁 前 系统 、 搭 建 图 形 系 
统 ， 甚 至 定制 桌面 环境 ， 这 些 相 关 知识 读者 在 本 书 中 都 可 以 找到 。 


人 Linux 发 行 版 工程 师 。 作 为 制作 发 行 版 的 工程 师 ， 更 需要 彻底 熟 
悉 操 作 系 统 的 每 个 组 件 以 及 组 件 间 的 关系 ， 本 书 可 以 满足 他 们 这 方面 
的 需求 。 


争 Linux 应 用 开发 工程 师 。 对 于 应 用 开发 程序 员 ， 也 推荐 阅读 本 
书 ， 因 为 越 深 入 地 理解 操作 系统 和 编译 链接 原理 ， 就 越 能 写 出 高 效 而 


简洁 的 程序 。 


如 何 阅 谈 本 书 


本 书 围绕 着 构建 一 个 完整 的 Linux 操 作 系 统 这 一 主线 展开 ， 除 了 第 
1 章 外 ， 其 余 各 章 环 环 相 扣 ， 所 以 请 读者 挛 格 按照 章节 有 顺序 阅读 。 


工 欲 墙 其 事 ， 必 先 利 其 右 。 尤 其 是 对 于 这 样 一 本 实践 丰富 的 书 来 
说 ， 工 作 环境 是 后 续 内 容 的 基础 。 因 此 ， 第 1 章 介 绍 了 如 何 准备 工作 环 
境 。 但 是 类 似 安装 Linux 发 行 版 这 样 的 内 容 ， 相 关 参 考 随 处 可 见 ， 因 此 
书 中 并 没有 滔 费 篇 幅 去 一 一 介绍 ， 而 是 仅仅 指出 其 中 需要 特别 注意 之 
处 。 


工具 链 是 后 面 进行 构建 的 基础 ， 因 此 ， 接 下 来 在 第 2 章 中 构建 了 工 
具 链 。 工 具 链 是 整个 操作 系统 中 非常 重要 的 一 部 分 ， 理 解 工 具 链 的 工 
作 原 理 ， 对 理解 操作 系统 至 关 重 要 ， 所 以 第 2 草 中 并 没有 仅仅 停留 在 构 
建 的 层次 ， 还 通过 探讨 编译 链接 过 程 ， 讨 论 了 工具 链 的 组 成 以 及 各 个 
组 件 的 作用 。 


在 第 3 章 和 第 4 章 ， 我 们 从 零 开 始 ， 构 建 了 一 个 具备 用 户 字 符 界 面 
的 最 小 操作 系统 。 同 时 在 第 5 章 ， 我 们 从 更 深层 次 的 角度 探讨 了 这 一 切 
征 如 何 发 生 的 。 我 们 从 内 核 的 加 载 、 解 讨 一 直 讨 论 到 用 户 进程 的 加 
载 ， 包 括 用 户 空间 的 动态 链接 硕 为 加 载 程序 所 做 的 努力 。 


在 第 6 章 和 第 7 章 ， 我 们 首先 构建 了 系统 的 基础 图 形 系统 ， 然 后 在 
其 上 构建 了 桌面 环境 。 在 第 8 章 ， 我 们 深入 探讨 了 计算 机 图 形 的 基础 原 
理 ， 讨 论 了 2D 和 和 3D 程序 的 泻 染 、 软 件 泻 染 、 人 硬件 泻 染 ， 我 们 也 从 操作 
系统 的 角度 审视 了 Pipeline 。 


笔者 强烈 建议 读者 在 真实 的 计算 机 上 安装 一 个 Linux 操 作 系 统 ， 让 
它 成 为 你 日 第 的 工作 机 。 然 后 将 书 中 的 ， 尤 其 是 与 实践 相关 的 所 有 命 
令 实际 运行 一 过 。 之 后 再 答 试 脱离 本 书 ， 目 己 和 争取 从 头 再 构建 一 过 ， 
相信 你 一 定 会 在 这 个 过 程 中 受益 菲 浅 的 。 


惑 误 和 文 持 


由 于 作者 水 平 有 限 ， 加 之 编写 时 间 人 仓促， 书 中 难免 会 出 现 一 些 错 
误 或 者 不 准确 的 地 方 ， 奶 请 读者 提出 宝 中 意见， 批评 指正 。 来 信 请 发 
送 至 邮箱 baisheng_wang@163.com， 笔 者 会 尽 目 己 最 大 的 努力 给 出 回 
复 o 


致谢 


首先 感谢 恩师 李 明 树 先生 ， 十 他 将 我 市 进 了 操作 系统 这 而 大 门 。 


感谢 机 械 工业 出 版 社 华 革 公 司 的 策划 杨 福 川 ， 在 他 身上 我 看 到 了 
专业 精神 ， 这 也 是 我 在 与 几 个 出 版 团队 沟通 后 ， 受 不 犹豫 地 决定 请 他 
们 出 版 的 原因 。 


感谢 机 械 工 业 出 版 社 华 章 公 司 的 妆 影 编辑 ， 她 清晰 的 思路 让 我 深 
深 折 服 。 每 每 在 过 到 困惑 不 知 如 何 表达 时 ， 她 都 能 通过 人 稍 单 的 儿 句 话 
点 醒 梦 中 人 。 


感谢 我 的 父母 ， 感 谢 他 们 的 养育 之 恩 。 感 谢 我 的 哥哥 ,为 了 让 我 
受到 更 好 的 教育 ， 在 他 刚刚 毕业 不 久 ， 束 项 着 生活 的 压力 ， 将 我 从 农 
村 接 到 了 城 里 接受 教育 ， 为 我 的 学 业 奔 波 操 劳 。 感 谢 我 的 嫂子 在 生活 
上 给 予 我 的 无 微 不 至 的 照顾 。 把 最 后 一 份 感谢 留 给 我 的 妻子， 是 她 在 
我 工作 这 些 年 ， 承 担 了 照顾 父母 、 操 持家 务 的 重任 ， 是 她 的 无 私 付出 
让 我 能 全 身心 地 投入 到 工作 和 学 习 中 。 


至 作 生 


北京 


第 1 草 ”准备 基本 环境 


在 开始 Linux 操 作 系 统 的 探索 旅程 之 前 ， 我 们 首先 需要 准备 一 下 环境 ， 
读者 最 好 在 真实 的 计算 机 上 安装 一 个 Linux 操 作 系统 作为 工作 机 。 侣 无 疑 
问 ， 使 用 是 最 好 的 学 习 方 法 ， 如 果 日 弟 工 作 系 统 也 十 Linux， 那 么 这 无 疑 有 
助 于 更 好 地 理解 Linux 操 作 系统 。 但 是 这 不 是 必须 的 ， 也 可 以 安 朔 一 人 台 虚 拟 
机 作为 工作 机 。 鉴 于 现在 的 Linux 发 行 版 的 安 狠 过 程 非常 友好 和 目 动 化 ， 本 
章 无 意 浪 费 版 面 介绍 其 安装 过 程 。 


男 外 ， 在 构建 操作 系统 时 ， 需 要 频繁 重启 系统 ， 因 此 强烈 建议 读者 不 
要 使 用 工作 机 作为 实验 机 ， 而 是 另外 安装 一 台 虚 拟 机 作为 实验 机 。 本 章 将 
介绍 如 何 创建 一 个 虚拟 的 裸 机 以 及 如 何在 其 上 安装 Linux 操 作 系统 ， 并 且 介 
绍 为 了 后 面 的 开发 和 调试 ， 在 虚拟 机 上 需要 进行 的 一 些 必要 的 准备 。 


因为 梨 面 环境 可 以 利用 一 个 模拟 的 小 X 服 务 套 Xephyr 来 调试 ， 所 以 我 们 
可 以 先 在 箱 主 机 的 Xephyr 上 进行 开发 和 调试 ， 然 后 再 到 构建 的 真实 系统 上 
调试 。 因 此 ， 本 章 的 最 后 一 部 分 介绍 了 如 何 使 用 Xephyr。 


1.1 安装 VirtualBox 


笔者 建议 在 真实 的 计算 机 上 安装 一 个 Linux 操 作 系统 ， 这 个 系统 作为 工 
作 机 ， 主 要 进行 编译 、 构 建 和 开发 ， 男 外 辅助 提供 做 一 些 实验 及 阅读 源 代 
码 等 。 理 论 上 使 用 哪 家 的 发 行 版 或 者 哪个 版 本 都 可 以 ， 但 是 为 了 避免 意外 


的 万 烦 ， 建 议 使 用 和 笔者 相同 的 环境 。 在 写作 这 本 书 的 最 后 ， 笔 者 使 用 
Ubuntu12.10 将 构建 过 程 全 部 验证 了 一 人 裔 ， 所 以 建议 读者 也 使 用 这 个 版 本 。 


另外 ， 我 们 当然 不 希望 使 用 工作 机 调试 我 们 构建 的 操作 系统 ， 因 为 这 
样 需 要 频繁 的 启动 。 所 以 我 们 需要 一 个 虚拟 机 ， 笔 者 使 用 的 虚拟 机 是 


VirtualBox。 在 Ubuntu12.10 下， 使 用 如 下 命令 安装 VirtualBox: 


root@baisheng:~# apt-get install virtualbox 


因为 我 们 是 从 零 开 始 构 建 系 统 ， 因 此 虚拟 机 上 还 需要 一 个 额外 的 Linux 
系统 作为 桥 染 。 鉴 于 其 只 是 一 个 桥梁 ， 所 以 使 用 什么 版 本 没有 关系 ， 比 如 
笔者 虚拟 机 上 使 用 的 是 Ubuntu11.10。 


1.2 创建 虚拟 计算 机 


在 安装 Linux 操 作 系统 之 前 ， 我 们 需要 从 硬件 层面 创建 一 个 虚拟 的 
计算 机 。VirtualBox 局 动 后 ， 主 界面 如 网 1-1 所 示 。 


Oracle VM VirtualBox 管理 器 


地 当 杀 人 | 雹 明 组 D)| 加 各 份 人 


新 建 (N) 设置 (S) 启动 (T) 清除 


x pope 加 常规 凤 预览 
EP 归 下 7 名 称 : 11.10 
系统 类 型 : Ubuntu 


系统 

内 存 大 小 : 394 MB 

启动 顺序 : 软驱 , 光驱 , 硬盘 

硬件 加 速 : VT-x/AMD-V, 庶 套 
分 页 , PAE/NX 


显示 
显存 大 小 : 12 MB 
远程 桌面 服务 器 : 禁用 


@ 存储 
IDE 控制 器 
第 二 IDE 控 制 器 主 通道 ( 光 没有 盘 片 
驱 ): 
SATA 控制 器 
SATA 端口 0: 11.10.vdi.vdi (普通 , 8.00 GB) 


伽 声音 


rm Tr ETI ET HT 一 


图 1-1 VirtualBox 主 界面 


单 击 图 1-1 中 VirtualBox 主 界面 工具 条 中 的 “新 建 ? 按 钮 ， 新 建 虚 拟 机 
的 向 导 将 启动 。 这 个 过 程 非常 简单 ， 读 者 按照 新 建 向 导 一 路 执行 下 去 


就 好 。 读 者 只 需要 注意 在 安 闭 过 程 中 要 选择 安装 Linux 操 作 系统 ， 其 他 
全 部 默认 即 可 。 


创建 好 虚拟 机 后 ， 在 VirtualBox 主 界面 中 将 出 现 新建 的 虚拟 裸 机 ， 
如 图 1-2 所 示 ， 其 中 ，ubuntu11.10 就 是 笔者 新 创建 的 虚拟 机 。 


1.3 ”安装 Linux 系 统 


本 市 我 们 将 在 1.2 市 创建 的 裸 机 上 安装 Linux 操 作 系 统 。 


在 图 1-2 所 示 的 工具 栏 上 单 击 “ 设 置 ” 按 钮 ， 当 然 要 确保 在 左 侧 的 列 
表 中 选中 的 是 刚刚 创建 的 裸 机 ， 出 现 如 图 1-3 所 示 的 界面 。 


Oracle VM VirtualBox 管理 器 


志 都 哆 风 国明 旺 加 | 加 备份 人 


新 建 (N) 设置 (S) 启动 (T) 清除 


WN x > 网 常规 加 预览 
喝 下 站 运 和 名 称 : ubuntu11.10 

区 系统 类 型 : Ubuntu 
[ER 


11.10 
句 已 关闭 
系统 
内 存 大 小 : 512 MB Ubuntu11.10 
启动 顺序 : 软驱 , 光驱 , 硬盘 
硬件 加 速 : VT-x/AMD-V, 该 套 
分 页 , PAE/NX 
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图 显示 


显存 大 小 : 12 MB 
远程 桌面 服务 器 : 禁用 


图 存储 
IDE 控制 器 
第 二 IDE 控 制 器 主 通道 ( 光 没有 盘 片 
驱 ): 
SATA 控制 器 
SATA 端口 0: ubuntu11.10.vdi (普通 , 8.00 GB) 


防 声音 


mh AT TI ， mm Tr HT 一 如 


图 1-2 新 建 的 虚拟 课 机 


Ubuntu11.10 - 设置 


加 常规 存储 

系统 

显示 存储 树 (5) 属性 

@ 存储 使 IDE 控 制 器 分 配 光驱 (D): | 第 二 IDE 控 制 器 主 通 j ; @ 
了 声音 站 演示 (Uivej 光 盘 人 

田 网 络 会 SATA 控制 器 明细 

从 串口 Ubuntu11.10.vdi 类 型 . - 

多 USB 设 备 容量 大 小 : - 

共享 文件 夹 位 置 : - 


晤 全 全 
选择 用 于 虚拟 驱动 器 的 虚拟 光盘 或 物理 光驱 。 上 虚拟 机 将 会 看 到 插入 的 光盘 
上 的 数据 . 


_ 部 助 OH) | 取消 C) | 攻 EEG 司 


图 1-3 载 入 虚拟 光 胡 映 像 


在 图 1-3 中 ， 首 先 在 左 侧 的 列表 中 选择 “存储 ”。 在 默认 情况 下 ， 我 
们 会 看 到 虚拟 机 已 经 添加 了 一 个 空 的 虚拟 光驱 。 如 果 VirtualBox 没 有 自 
动 添加 ， 读 者 手动 添加 即 可 。 至 于 是 SATA 接 口 还 是 IDE 接 口 ， 是 没有 
关系 的 ， 毕 竟 是 虚拟 的 。 然 后 ， 选 中 虚拟 光驱 ， 即 图 1-3 所 示 的 IDE 控 
制 器 下 的 “没有 盘 片 ， 然 后 单 击 “ 分 配 光 驱 * 文 本 框 旁 的 带 有 光盘 图 片 的 


按钮 。VirtualBox 将 打开 一 个 文件 选择 对 话 框 ， 读 者 找到 Linux 操 作 系 统 
的 光盘 映像 即 可 。 这 个 过 程 与 我 们 将 物理 光 胡 放 入 光驱 道理 完全 相 
同名 


在 将 光盘 映像 放 入 虚拟 光驱 后 ， 在 图 1-2 所 示 的 界面 中 单 击 工 具 栏 
上 的 “启动 ”按钮 ， 局 动 Linux 系 统 的 安装 过 程 。 鉴 于 现在 的 发 行 版 的 安 
法 过 程 非常 友好 且 全 程 自 动 化 ， 我 们 就 不 再 浪费 太 多 版 面 逐 一 介绍 。 
其 中 需要 读者 重点 关注 的 是 一 定 要 从 硬盘 中 为 我 们 即将 构建 的 系统 划 
分 出 一 块 分 区 ， 基 本 上 2GB 就 足够 了 ， 并 将 其 格式 化 为 EXT4 类 型 ， 当 
然后 面 这 一 步 也 可 以 在 系统 安装 完成 后 进行 。 


在 安装 过 程 中 ， 在 选择 安装 类 型 (installation type) 这 一 步 ， 务 必 
要 选择 "Something else"， 如 果 选 择 了 使 用 中 文 简 体 安装 ， 这 里 显示 的 
可 能 是 “其 他 选项 *， 总 之 ， 要 选择 这 个 允许 我 们 为 硬盘 分 区 的 选项 ， 
如 图 1-4 所 示 。 


Install 


Installation type 


Erase disk and install Ubuntu 
Warning: This will delete any files on the disk. 


Something else 
® You can create or resize partitions yourself or choose 
multiple partitions for Ubuntu. 


This computer currently has no detected operating systems. What would you like to do? 


Back || Continue | 


= 


单 击 图 1-4 中 的 继续 (Continue) 按钮 ， 将 出 现 硬 盘 分 区 的 界面 。 
基本 上 划分 两 个 分 区 就 可 以 了 ， 一 个 用 来 安装 操作 系统 ， 另 外 一 个 作 
为 “实验 田 "”， 留 给 我 们 构建 的 操作 系统 用 于 实验 。 划 分 好 的 分 区 大 致 


如 图 1-5 所 示 。 


Install 


Installation type 


国 sda1 (ext4) 国 sdaz (ext4) 
6.0 GB 2.6 GB 


Device Type Mountpoint | Format? size Used 


/dev/sdal ext4 / A 5998MB unknown 
/dev/sda2 ext4 J 2588 MB unknown 


| New Partition Table...| Add... |Change...” Delete |Revert 


Device for boot loader installation: 


| /dev/sda AIAVBOXHARDDISK(8.6GB) 


™ 


Back | | Install Now | 


图 1-5 硬盘 分 区 


另外 ， 还 有 一 处 需要 提醒 读者 ， 在 安装 的 后 期 ， 安 装 程 序 可 能 会 
通过 网 络 更 新 系统 ， 因 为 这 个 虚拟 机 上 的 系统 只 是 一 个 桥梁 ， 没 有 太 
多 工作 要 做 ,一 个 基本 的 系统 束 足 够 了 ， 所 以 完全 没有 必要 当 费 时 间 
等 待 其 下 载 更 新 ， 直 接 略 过 (skip) 即 可 。 


1.4 使 用 root 用 户 


很 多 发 行 版 由 于 安全 原因 ， 默 认 使 用 普通 用 户 登 录 ， 因 此 当 要 执 
行 一 些 需 要 特权 的 操作 时 ， 人 往往 需要 通过 "sudo" 命 令 使 目 己 临时 成 为 
root 用 户 。 但 是 这 对 于 我 们 希望 研究 操作 系统 的 人 来 说 ， 当 然 有 后 不 
方便 了 ， 所 以 ， 笔 者 建议 使 用 root 用 户 登 录 。 


既然 打算 使 用 root 用 户 ， 当 然 要 知道 root 用 户 的 密码 了 ， 但 是 
Ubuntu 默认 的 root 用 户 密码 是 什么 呢 ? 不 必 理 会 这 个 问题 ， 直 接 改 成 
我 们 目 己 的 即 可 。 以 普通 用 户 登 录 虚 拟 机 后 ， 局 动 一 个 终端 ， 执 行 如 
下 命令 修改 root 用 户 密码 : 


sudo passwd root 


然后 就 可 以 使 用 root 用 户 了 ， 或 者 使 用 命令 "su" 切 换 用 户 ， 或 者 登 
录 时 使 用 root 用 户 。 


1.5 ”局 用 目 动 登录 


在 安 闭 步 又 中 ， 在 添加 用 户 这 一 步 的 界面 中 ， 有 一 个 可 选项 ， 
即 “ 自 动 登录 ”(log in automatically) ， 这 个 选项 默认 是 没有 选中 的 。 
如 采 没 有 选中 ， 那 么 在 局 动 时 ， 每 次 登 孙 都 需要 输入 登 孙 密码 ， 非 党 
磋 焕 。 所 以 ， 建 议 读者 开启 目 动 登 录 。 


如 果 安 装 时 没有 选中 ， 也 不 必 重 新 安装 。 读 者 可 以 修改 登录 管理 
侣 lightdm 的 配置 文件 lightdm.conf， 在 其 中 添加 下 面 一 行 : 


/etc/lightdm/lightdm.conf: 


autologin-user=root 


如 采 读 者 实在 不 愿意 厂 击 键盘 输入 这 几 个 字母 ， 那 么 可 以 在 系统 
设置 中 ， 打 开 “ 用 户 账户 ”(User Accounts) ， 将 普通 账户 的 “自动 登 
录 ”(Automatic Login) 开启 ， 然 后 在 配置 文件 lightdm.conf 中 将 多 出 类 
似 下 面 一 行 : 


/etc/lightdm/lightdm.conf: 


autologin-user=baisheng 


读者 将 其 中 的 普通 用 户 的 登录 名 改 为 root 妈 可。 


如 此 ， 即 可 免除 每 次 登录 时 输入 密码 之 特 ， 也 无 需 手动 切换 用 
户 ， 而 是 目 动 以 root 号 份 登 录 。 


1.6 ” 挂 载 实验 分 区 


假设 在 虚拟 机 上 为 构建 的 操作 系统 划分 的 分 区 是 /dev/sda2， 那 么 
我 们 使 用 如 下 命令 将 其 挂 载 在 根 目录 的 vita 下 : 


mkdir /vita 
mount /dev/sda2 /vita 


为 了 避免 每 次 开机 后 都 需要 手工 挂 载 ， 我 们 将 其 写 入 fstab 文 件 
中 ， 开 机 后 由 操作 系统 目 动 挂 载 : 


/etc/fstab: 


/dev/sda2 /vita ext4 defaults 0 0 


1.7 ”安装 ssh 服 务 器 


我 们 使 用 ssh 服 务 从 宿主 系统 同 虚 拟 机 复制 构建 的 实验 系统 。 
此 ， 在 虚拟 机 系统 上 需要 安装 ssh 服 务 器 。ssh 服 务 器 需要 通过 网 络 从 
源 服 务 器 下 载 。 以 笔者 使 用 的 VirtualBox 版 本 为 例 ， 默 认 其 为 虚拟 机 开 
司 了 网 络 ， 并 且 使 用 的 是 NAT 模 式 ， 要 访问 互联 网 ， 无 需 设置 IP、 路 
由 等 ， 但 是 要 目 己 设置 DNS。 或 者 直接 可 以 进入 设置 ， 将 虚拟 机 的 网 
络 改 为 桥接 模式 ， 这 样 在 DHCP 的 网 络 环境 中 ， 无 须 做 任何 修改 即 可 
访问 互联 网 。 


确保 虚拟 机 可 以 访问 互联 网 后 ， 我 们 整 可 以 安 洲 ssh 服 务 嚣 了。 当 
然 蛙 次 从 源 安 狠 软件 时 ， 需 要 更 新 源 。 更 新 源 和 安 狐 ssh 服务 的 命令 如 
下 : 


apt-get update 
apt-get install openssh-server 


1.8 更 改 网 络 模式 


在 VirtualBox 的 各 种 网 络 模 式 中 ， 人 允许 答 主 机 和 虚拟 机 通信 的 第 用 
网 络 模式 是 桥接 模式 和 Host-Only 模 式 。 但 是 桥接 模式 有 两 个 问题 ， 一 
个 是 窒 主 机 一 定 要 时 刻 连 网 ， 因 为 在 桥接 模式 下 ， 虚 拟 机 在 局 域 网 内 
被 模拟 为 与 宿主 机 同等 地 位 的 一 台 主 机 ， 所 以 如 琳 答 主机 没有 接 入 局 
域 网 ， 何 谈 虚拟 机 和 答 主 机 通信 ? 虽然 现在 网 络 很 普及 ， 但 是 毕竟 会 
我 们 也 不 想 让 开 着 ssh 服 务 


存在 未 接 入 网 络 的 情况 。 另 外 一 个 问题 是 ， 
器 的 虚拟 机 又 露 在 互联 网 上 。 所 以 ， 笔 者 建议 虚拟 机 的 网 络 使 用 Host- 


Only 模 式 ， 设 置 方 法 如 图 1-6 所 示 。 


Ubuntu11.10 - 设置 


加 常规 网 络 
系统 
显示 网 卡 1 | 网 卡 Z | 网 卡 3 网 卡 4 
图 存储 
声音 ee 
画 网 络 连接 方式 (A): | 仅 主机 (HostOnly) 适 配器 : 
俏 串口 界面 名 称 (N): | vboxnet0 | 
多 USB 设 备 二 高 级 (d) 


共享 文件 夹 


控制 心 片 人 TIncel PRO/19090 MT 桌面 |( 


混杂 模式 (P): | 拒绝 


MAC 地 址 (M): |080027378151 多 
图 按 入 网 线 (C) 
活 口 转发 (P 


村 助 (H) _ 取消 (C_| EB 
图 1-6 设置 虚拟 机 网 络 模式 


在 图 1-6 中 ， 首 先 选 中 左 侧 列表 中 的 “网 络 "， 然 后 将 “连接 方式 ”更 
改 为 "Host-Only" 模 式 。 


确定 后 ， 宿 主 系统 将 多 出 一 个 网 络 接口 ， 用 于 与 虚拟 机 通信 ， 默 
认 一 般 是 vboxnet0， 其 地 址 被 设置 为 192.168.56.1， 虚 拟 机 的 地 址 被 设 
置 为 192.168.56.101。 当然 读者 可 以 目 己 修改 ， 但 是 这 没有 任何 必要 。 


然后 在 虚拟 机 上 我 们 束 可 以 使 用 如 下 命令 局 动 ssh 服 务 器 了 : 


/usr/sbin/sshad 


在 答 主 系统 上 ， 我 们 可 以 远程 登录 到 虚拟 机 ， 命 令 如 下 : 


SS 192.168550s E01 


也 可 以 将 宿主 系统 的 文件 (比如 a) 复制 到 虚拟 机 ， 命 令 如 下 : 


Bop: a .J92s168 56: L101 /ro0ty 


1.9 安 冯 增强 模式 


当 没 有 安 逆 增强 模式 时 ， 虚 拟 机 只 能 使 用 固定 的 分 辨 率 ， 那 么 可 
能 不 文 持 全 屏 这 样 的 功能 。 如 果 和 需要 全 屏 功 能 ， 可 以 选择 安 闭 
VirtualBox 的 增强 功能 来 解决 这 一 问题 。 


在 VirtualBox 的 亲 单 中 ， 前 先 选 择 “ 设 备 ” 采 单 ， 然 后 在 下 拉 菜 单 中 


选择 “安装 增强 功能 ”。 


增强 功能 也 在 一 个 光盘 映像 中 ， 所 以 如 果 是 首次 安装 增强 功能 ， 
VirtualBox 将 首先 从 网 络 上 下 载 这 个 光盘 映像 到 宿主 机 。 下 载 完 成 后 ， 
这 个 光盘 映像 一 般 会 被 自动 装 入 到 虚拟 光驱 ， 如 果 没 有 自动 挂 载 ， 需 
要 读者 手动 将 其 放 入 到 虚拟 光驱 ， 然 后 ， 运 行 其 中 
的 "VBoxLinuxAddtions.run" 即 可 。 当 然 如 采 是 为 Windows 系 统 安装 增 
强 功能 ， 需 要 运行 相应 的 Windows 版 本 。 


1.10 ”使 用 Xephyr 


在 入 主 系统 上 使 用 Xephyr 调 试 蝎 面 环境 ， 要 更 方便 一 些 。 所 以 这 
玉 ， 我 们 介绍 如 何在 御 主 系统 上 调试 揭 面 环境 。 如 果 尚 未 安 痛 Xephyr， 册 
首先 通过 如 下 方法 安 厂 Xephyr: 


root@baisheng:~# apt-get install xserver-xephyr 
然后 使 用 如 下 命令 启动 Xephyr: 

root@baisheng:~# Xephyr -ac -screen 800x480 :1.0 
在 男 外 的 终端 中 ， 将 Display 定 癌 到 Xephyr: 


root@baisheng:~# export DISPLAY=:1.0 


如 此 ， 在 这 个 终端 中 ， 所 有 需要 X 服 务 器 泻 染 程序 都 将 使 用 Xephyr。 当 
然 ， 为 了 方便 ， 我 们 可 以 开启 任意 个 终端 ， 并 将 它们 的 Display 都 定 癌 到 
Xephyr ° 


比如 我 们 可 以 在 一 个 终端 中 运行 窗口 管理 磊 winman: 


root@baisheng:~# export DISPLAY=:1.0 
root@baisheng:/vita/build/winman/src# ./winman 


在 男 外 一 个 终端 中 运行 任务 条 : 


root@baisheng:~# export DISPLAY=:1.0 
root@baisheng:/vita/build/taskbar/src# ./taskbar 


而 在 第 三 个 终端 中 运行 Desktop 程 序 : 


root@baisheng:~# export DISPLAY=:1.0 
root@baisheng:/vita/build/desktop/src# ./desktop 


图 1-7 就 是 在 笔者 的 宿主 机 上 运行 winman 以 及 一 个 gedit 后 的 Xephyr 。 
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图 1-7 Xephyr 


第 2 章 工具 链 


软件 的 编译 过 程 中 由 一 系列 的 步骤 完成 ， 每 一 个 步 又 都 有 一 个 对 应 的 
工具 。 这 些 工具 紧密 地 工作 在 一 起 ， 前 一 个 工具 的 输出 征 后 一 个 工具 的 输 
入 ， 像 一 根 链条 一 样 ， 因 此 ， 人 们 也 把 这 些 工具 的 组 合 形象 地 称 为 工具 
链 。 


在 本 书 中 ， 我 们 将 从 源码 开始 ， 逐 步 构建 一 个 基本 的 Linux 操 作 系统 。 
显然 ,工具 链 是 我 们 首先 需要 考虑 的 ， 因 为 工具 链 十 编译 包括 内 核 在 内 的 
操作 系统 各 个 组 件 的 基础 。 正 所 谓 “ 物 有 本 末 ， 事 有 终 始 ， 知 所 先后 ， 则 近 
道 全 。” 因 此 ， 在 本 章 中 ， 我 们 并 没有 匆忙 切入 正题 一 一 构建 工具 链 ， 而 是 
首先 结合 具体 的 例子 ， 借 助 和 宿主 系统 中 的 工具 ， 尽 可 能 地 将 工具 链 的 工作 
过 程 更 具体 地 展示 给 读者 。 布 望 通过 这 个 探讨 过 程 ， 读 者 可 以 明日 工具 链 
包含 哪些 组 件 以 及 这 些 组 件 的 基本 工作 原理 。 然 后 基于 GNU 工 具 链 的 源 
码 ， 手 工 从 源码 构建 一 套 工具 链 。 后 面 ， 我 们 将 会 使 用 这 一 章 构建 的 工具 
链 编译 内 核 以 及 操作 系统 的 各 个 组 件 。 


2.1 编译 过 程 


在 Linux 系 统 上 ， 通 常 ， 只 需 使 用 gcc 束 可 以 完成 整个 编译 过 程 。 但 不 要 
被 gcc 的 名 字 误 导 ， 事 实 上 ，gcc 并 不 是 一 个 编译 器 ， 而 是 一 个 驱动 程序 
(driver program) 。 在 整个 编译 过 程 中 ，gcc 就 像 一 个 导演 一 样 ， 编 译 过 程 


中 的 每 一 个 环 下 由 具体 的 组 件 负 责 ， 如 编译 过 程 由 ccl1 负 责 、 汇 编 过 程 由 as 
、 链接 过 程 由 ld 负责 。 


我 们 可 以 通过 传递 参数 "-v" 给 gcc 来 观察 一 个 完整 的 编译 过 程 中 包含 的 
步 台 ， 下 面 是 一 个 典型 的 编译 过 程 中 gcc 的 输出 信息 ， 为 了 更 清楚 地 看 到 编 
译 过 程 中 的 主要 步 又 ， 对 输出 信息 进行 了 适当 删 减 。 


root@baisheng:~/demo# gcc -V main.c 


/usr/lib/gcc/i686-linux-gnu/4.7/ccl1 -quiet -vv -imultiarch 
i386-linux-gnu main.c -quiet -dumpbase main.c -mtune=generic 
-march=i686 -auxbase main -version -fstack-protector -o 
tmp/ccYBInzt.s 


as -V --32 -o /tmp/ccj54pkM.o /tmp/ccYBInzt.s 


/usr/lib/gcc/i686-linux-gnu/4.7/collect2 --sysroot=/ --build-id 
--no-add-needed --as-needed --eh-frame-hdr -m elf i386 
--hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -z relro 
usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crtl.o 
/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crti.o 
/usr/lib/gcc/i686-linux-gnu/4.7/crtbegin.o 
-L/usr/lib/gcc/i686-linux-gnu/4.7 
-L/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu 
-Li/usr/l1ib/gee/1686-1inux-gnu/4 :7/6 /ss/ Ai 
-L/lib/i386-linux-gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu 

二 了 /三 入 下 大生/ /Ti =L/VBE/IID/gee/ i606- Tea ry i 
/tmp/ccj54pkM.o -lgcc --as-needed -lgcc s --no-as-needed -lc -lgcc 
--adsS-needed -lgcece 5 --no-as-needed 
/usr/lib/gcc/i686-linux-gnu/4.7/crtend.o 
/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crtn.o 


根据 gcc 的 输出 可 见 ， 对 于 一 个 C 程 序 来 说 ， 从 源 代码 构建 出 可 执行 程 
序 经 过 了 三 个 阶段 : 


gcc 调 用 编译 属 ccl 进 行 编译 ， 产 生 的 汇编 代码 保存 在 目 孙 /imp 下 的 文件 
ccYBInzt.s 中 。 


(2) 汇编 


gcc 调 用 汇编 器 as， 汇 编 编译 过 程 产 生 汇编 文件 cca2nBio.s， 产 生 的 目标 
文件 保存 在 目录 /tmp 下 的 文件 ccj54pkM.o 中 。 


(3) 链接 


我 们 看 到 ，gcc 并 没有 如 我 们 想象 的 那样 直接 调用 ld 进行 链接 ， 而 是 调 
用 collect2 进 行 链接 。 实 际 上 ，collect2 只 是 一 个 辅助 程序 ， 最 终 它 仍 将 调用 
链接 器 ld 完成 真正 的 链接 过 程 。 举 个 例子 ， 对 于 C++ 程 序 来 说 ， 在 执行 main 
函数 前 ， 全 局 静态 对 象 必 须 构造 完成 。 也 就 是 说 ， 在 main 之 前 程序 需要 进 
行 一 些 必 要 的 初始 化 ，gcc 就 是 使 用 collect2 安 排 初始 化 过 程 中 如 何 调用 各 个 
初始 化 函数 的 。 根 据 链 接 过 程 可 见 ， 除 了 main.c 对 应 的 目标 文件 ccj54pkM.o 
外 ，1d 也 链接 了 libc、1libgcc 等 库 ， 以 及 所 谓 的 包含 启动 代码 (start code) 的 
启动 文件 (start/startup file) ， 包 括 crt1.0、crti.o、crtbegin.0、crtend.o 和 


Crtn.0 ° 


事实 上 ， 对 于 C 程 序 来 说 ， 编 译 过 程 也 可 以 拆 分 为 两 个 阶段 ， 预 编译 
(或 称 为 编译 预 处 理 ) 和 编译 。 所 以 ， 软 件 构建 过 程 通常 分 四 个 阶段 : 预 
编译 、 编 译 、 汇 编 以 及 链接 ， 如 图 2-1 所 示 。 
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图 2-1 C 程 序 的 构建 过 程 


在 接 下 来 讨论 编译 过 程 的 章节 中 ， 如 无 特殊 说 明 ， 都 将 以 下 面 的 程序 
为 例 。 


EGOT. 
Ei O01 二 于 0 


void fool func () 


{ 


nt Eet SS E60 


O02 
1nt f602 三 205 


EUR Rl 


} 


hello.c: 


int ret = foo2; 


#include <stdio.h> 
extern int foo2; 


4rt. maim(int arges ehar *argwv lj) 
{ 

foo2 三 5; 

foo2 func(S50) 

return 0; 


2.1.1 ” 预 编译 


在 预 编 译 阶段 ， 预 编译 器 将 处 理 源 代 码 中 的 预 编译 指令 。 一 般 而 言 ，C 
语言 中 的 预 编译 指令 以 “#5? 开头 ， 和 常 用 的 预 编译 指令 包括 文件 包含 合 
令 "#include"、 宏 定义 "#define"， 以 及 条 件 编译 命 


令 "##f"、"#else"、"#endif" 等 。 


在 工具 链 中 ， 一 般 都 提供 单独 的 预 编译 占 ， 比 如 GCC 中 提供 的 预 编译 
器 为 cpp。 但 是 ， 因 为 预 编译 也 可 以 看 作 编译 过 程 的 第 一 壳 (first pass) ， 
古 为 编译 做 的 一 些 准 备 工作 ， 所 以 通常 编译 右 中 也 包 合 了 预 编 译 的 功能 。 
如 在 前 面 的 编译 过 程 中 ， 我 们 看 到 gcc 并 没有 单独 调用 cpp， 而 是 直接 调用 
ccl 进 行 编译 ， 原 因 束 在 于 此 。 


以 下 面 的 程序 为 例 ， 该 程序 使 用 了 典型 的 预 编译 指令 ， 我 们 通过 观察 
这 个 程序 的 预 处 理 的 结果 ， 来 直观 体会 预 编译 过 程 。 


Ff£OG;. Is 


#ifndef FOO H_ 
#define FOO H_ 


#define PI 3.1415926 
#define AREA 


steuvt E60 BUGSt 4 
1nt :Ss 
}; 
#endif 
hello.c: 
#include "foo.h" 
jnt main{int gc Char *argqvll) 


人 


int result.: 
I 全 全 B55 


#ifdef AREA 


上 二 :下 工 革 区 ES 
#else 
result .BL 2 


#endif 


} 


我 们 可 以 使 用 选项 -上 告诉 编译 侣 仅 作 预 处 理 ， 不 进行 编译 、 汇 编 和 链 
接 ， 具 体 命 令 如 下 : 


gcC -E hello.c -o hello.i 


预 编译 后 的 结果 保存 在 文件 hello.i 中 ， 其 内 容 如 下 : 


atruct foo struct { 


int a; 
int main(int argc, char *argv[l]) 
int result; 
nt LT = 5 
EeSULE 和 By L9926 洲 时 和 % 工 5 


根据 预 编译 后 的 结 采 可 见 ， 典 型 的 预 编译 指令 按照 如 下 方式 进行 处 
理 % 


(1) 文件 包含 


文件 包含 命令 指示 预 编 器 将 一 个 源 文件 的 内 容 全 部 复制 到 当前 源 文件 
中 。 在 上 面 的 代码 中 ，hello.c 使 用 命令 "#incude" 指 示 预 编 器 包含 文件 foo.h 。 
而 在 预 处 理 的 输出 文件 hello.i 中 ， 结 构 体 foo_struct 的 定义 确实 已 经 被 复制 到 
了 文件 hello.i 中 ， 也 就 是 说 ， 文 件 fooh 中 的 内 容 被 包含 到 了 文件 hello.i 中 。 


(2) 宏 定义 


SY 


宏 可 以 提高 程序 的 通用 性 和 易 读 性 ， 减 少 不 一 臻 性 和 输入 错误 ， 便 于 
维护 。 在 预 处 理 过 程 中 ， 预 编 器 将 宏 名 蔡 换 为 具体 的 值 。 比 如 ， 在 hello.c 的 
main 函 数 中 ， 经 过 预 处 理 后 ， 安 名 PI 已 经 被 奉 换 为 具体 的 值 3.1415926。 


(3) 条 件 编译 


在 大 多 数 情况 下 ， 源 程序 中 所 有 的 语句 都 参加 编译 ， 但 有 的 时 候 用 户 
斋 望 按照 一 定 的 条 件 去 编译 源 程 序 的 不 同 部 分 ， 这 时 可 以 使 用 条 件 编 译 。 
比如 在 函数 main 中 ， 当 定义 了 变量 AREA 时 ， 编 译 器 将 编译 "外 fdef" 块 的 代 
码 ， 否 则 编译 "#else" 块 的 代码 。 在 上 面 代码 中 ， 因 为 在 foo.h 中 定义 了 变量 
AREA， 所 以 ， 在 经 过 预 处 理 的 文件 hello.i 中 ， 条 件 编译 指令 中 的 "#else" 块 
的 代码 从 源 代码 中 被 删除 了 ， 只 保留 了 "##fdef" 块 的 代码 。 


2.1.2 ”编译 


编译 程序 对 预 处 理 过 的 结果 进行 词法 分 析 、 语 法 分 析 、 语 义 分 析 ， 然 
后 生成 中 间 代 码 ， 并 对 中 间 代 码 进行 优化 ， 目 标 是 使 最 终生 成 的 可 执行 代 
码 执行 时 间 更 短 、 占 用 的 空间 更 小 ， 最 后 生成 相应 的 汇编 代码 。 


以 foo2.c 为 例 ， 我 们 可 以 使 用 如 下 命令 指定 编译 过 程 只 进行 编译 ， 不 进 
行 汇编 和 链接 。 


root@baisheng:~/demo# gcc -S foo2.c 


编译 后 产生 的 谍 编 文 件 为 foo2.s， 其 内 容 如 下 : 


.file EoOd2uen 
‘TIOb1 ‘E002 

.data 

.align 4 

.type fo02, @object 
.Size EGO25 码 


foo2: 


foo2_func， 


的 伪 


(Ubuntu/Linaro 4.7.2-2ubuntul) 4 


aa 


.long 20 
te 
LDnDL Foo2 tun 
.type fo02 func, @function 
fo02 func: 
‘LFBO: 
.Cfi startproc 
pushl Sebp 
.Cfi def cfa offset 8 
Ch offset 5; <= 
movl Sesp, Sebp 
.Cfi def cfa register 5 
subl $16, Sesp 
movl foo2, $eax 
movl Seax, -4(%ebp) 
leave 
.Cfi restore 5 
.Cfi det cfa 4, 4 
ret 
.cfi endproc 
‘LFEO: 
.Size foo2 unGy, sfo02 funce 
‘lident "GCC: 
.Section 


.note.GNU-stack,'"",@progbits 


在 文件 foo2.c 中 ， 除 定义 了 一 个 全 局 变量 foo2 外 ， 仅 定义 了 一 个 函数 


。 伪 指令 是 不 参与 CPU 运行 的 ，4 


令 是 辅助 汇编 器 创建 栈 帧 (stack frame) 信息 


而 该 画 数 体 中 也 只 有 区 区 一 行 代码 ， 但 为 什么 产生 的 汇编 代码 
如 此 之 长 ? 事实 上 ， 仔 细 观 察 可 以 发 现 ， 文 件 foo2.s 中 相当 
指令 


码 中 以 ".cfi" 开 头 的 伪 指 


一 部 分 是 汇编 如 
只 指导 编译 链接 过 程 。 比 如 ， 代 
的。 


在 终端 上 调试 程序 的 程序 员 一 般 都 会 有 这 样 的 经 历 : 某 个 程序 出 现 
Segment Fault 了 ， 然 后 终端 中 会 输出 回溯 (backtrace) 信息 。 或 者 ， 我 们 在 
调试 程序 时 ， 也 经 常 需要 回溯 ， 查 找 一 些 变量 或 查看 函数 调用 信息 。 这 个 


过 程 ， 


就 是 所 谓 的 栈 的 回 卷 (unwind stack) 


。 事 实 上， 在 每 个 函数 调用 过 


程 中 ， 都 会 形成 一 个 栈 帧 ， 以 main 函 数 调用 foo2_func 为 例 ， 形 成 的 栈 帧 如 
图 2-2 所 示 。 


high address 


local variables y 
stack frame 


for main args for foo2 func 


return address 
for foo2 func 


ebp for main | 
ebp (frame/base pointer) 


stack frame 


local variables 
for foo2 func 


lowaddress \| | esp (stack pointer) 
图 2-2 函数 调用 中 的 栈 帧 


frame pointer 和 base pointer 鬼 指向 栈 桢 的 底部 ， 只 是 叫 法 不 同 ， 在 IA32 
架构 中 ， 通 党 使 用 寄存 器 ebp 保存 这 个 位 置 。 因 为 main 并 不 是 程序 中 第 一 个 
运行 的 函数 ， 所 以 main 也 是 一 个 被 调 函 数 ， 其 也 有 栈 帧 。 事 实 上 ， 即 使 程 
序 中 第 一 个 被 调用 的 函数 _start (该 贸 数 实现 在 启动 代码 中 ) ， 也 会 自己 模 
拟 一 个 栈 帧 。 


理论 上 ， 调 试 器 或 异常 处 理 程序 完全 可 以 根据 frame pointer 来 志 历 调用 
过 程 中 各 个 函数 的 栈 帧 ， 但 是 因为 gcc 的 代码 优化 ， 可 能 导致 调试 器 或 异常 


处 理 很 难 甚至 不 能 正常 回 蛮 栈 帧 ， 所 以 这 些 伪 指令 的 目的 吏 是 辅助 编译 过 
程 创建 栈 帧 信息 ， 并 将 它们 保存 在 目标 文件 的 段 ".eh_frame" 中 ， 这 样 束 不 会 


被 编译 万 优化 影响 了 。 


去 掉 这 些 伪 指令 后 ， 画 数 foo2_func 中 CPU 真正 执行 的 代码 如 下 : 


上 oo2i Funes 
pushl 
movl 
subl 
movl 
movl 
leave 
ret 


了 OOD Pp 


$ebp 

Sesp, Sebp 
$16, %esp 
foo2, Seax 
Seax, -4(%ebp) 


在 汇编 语言 中 ， 在 函数 的 开头 和 结尾 处 分 别 会 插入 一 人 小段 代码 ， 分 别 
称 为 Prologue 和 Epilogue， 如 foo2_func 中 的 第 1、2、3 行 代码 就 是 Prologue， 


第 6、7 行 代码 就 是 Epilogue 。 


Prologue 保 存 主 调 函 数 的 frame pointer， 这 是 为 了 在 子 贸 数 调 用 结 
后 ， 恢 复 主 调 函 数 的 栈 帧 。 同 时 为 子 函数 准备 栈 帧 。 其 主要 操作 包括 : 


多 保存 主 调 画 数 的 frame pointer， 如 第 1 行 代码 所 示 ， 就 是 将 保存 在 寄 
存 器 ebp 中 的 frame pointer 压 栈 。 在 退出 子 函 数 时 可 以 从 栈 中 恢复 主 调 函 数 的 


frame pointer ° 


令 将 esp 赋 值 给 sbp， 即 将 子 函 数 的 frame pointer 指 问 主 调 函 数 的 栈 顶 ， 
如 第 2 行 代 码 所 示 。 换 句 话 说 ， 这 行 代码 的 意义 就 是 记录 了 子 芳 数 的 栈 帧 的 


底部 ， 从 这 里 束 开 始 了 子 函 数 的 栈 帆 。 


令 修改 栈 顶 指针 esp ， 为 子 函 数 的 本 地 变量 分 配 栈 空 间 ， 如 第 3 行 代码 。 
注意 虽然 这 里 的 foo2_func 中 只 有 一 个 局 部 变量 ret， 占 据 4 字 世 ， 但 是 还 是 预 
留 了 16 字 节 的 栈 空间 ， 这 根据 的 是 IA32 的 ABI (Application Binary 
Interface) 的 16 字 节 的 对 齐 要 求 。 


Epilogue 功 能 与 Prologue 恰 恰 相 反 ， 如 果 说 Prologue 相 当 于 构造 函数 ， 那 
么 Epilogue 束 相当 于 析 构 函数 。 其 主要 操作 包括 : 


令 将 栈 指针 esp 指 癌 当前 子 函 数 的 栈 帧 的 frame pointer， 也 就 是 说 ， 指 癌 
当前 栈 顶 的 栈 底 ， 而 在 这 个 位 置 ， 恰 恰 是 Prologue 保 存 的 主 调 函 数 的 frame 
pointer。 然 后 ， 通 过 指令 pop 将 主 调 函 数 的 frame pointer 弹 出 到 ebp 中 ， 如 
此 ， 一 方面 释放 了 被 调 函 数 foo2_func 的 栈 帧 ， 同 时 也 回 到 了 主 调 函数 main 
的 栈 帧 。IA32 提 供 了 指令 leave 来 完成 这 个 功能 ， 即 第 6 行 代码 ， 这 个 指令 相 
当 于 : 


movl] %ebp, %esp 
pop %ebp 


令 将 调用 子 函 数 时 call 指 令 压 栈 的 返回 地 址 从 栈 顶 pop 到 EIP 中 ， 并 跳 转 
到 EIP 处 继续 执行 。 如 此 ，CPU 束 返回 到 主 调 函 数 继续 执行 。IA32 提 供 了 指 


令 ret 来 完成 这 个 功能 ， 即 第 7 行 代码 。 


除了 Prologue 和 Epilogue，foo2_func 的 核心 代码 就 剩 下 第 4 行 和 第 5 行 两 
了 了 。 这 两 行 代码 对 应 的 就 是 C 语 言 中 的 赋值 语句 "int ret=foo2"。 首 先 ， 即 


第 4 行 代码 ，CPU 从 数据 段 中 读 取 全 局 变量 foo2 的 值 到 寄存 器 EAX 中 。 然 
后 ， 即 第 5 行 代码 ， 将 eax 中 的 内 容 ， 即 foo2 的 值 ， 复 制 到 栈 中 的 局 部 变量 ret 
的 位 置 。 代 码 中 根据 局 部 变量 相对 于 栈 的 frame pointer (在 ebp 中 保存 ) 的 偏 
移 来 访问 局 部 变量 ， 如 变量 ret 位 于 相对 于 栈 的 偏 移 为 -4 的 内 存 处 。 


2.1.3 汇编 


汇编 郁 将 汇编 代码 翻译 为 机 天 指令 ， 每 一 条 汇编 语句 几乎 都 对 应 一 条 
机 器 指令 ， 所 以 汇编 颖 的 汇编 过 程 相对 于 编译 右 来 讲 比 较 们 单 ， 它 没有 复 
杂 的 语法 ， 也 没有 语义 ， 也 不 需要 做 指令 优化 ， 只 是 根据 汇编 指令 和 机 天 
日 令 的 对 照 表 进行 翻译 就 可 以 了 。 当 然 ， 汇 编 禹 的 工作 不 仅 包括 翻译 汇编 
指令 到 机 器 指令 ， 除 了 生成 机 器 码 外 ， 汇 编 器 还 要 在 目标 文件 中 创建 辅助 
链接 时 需要 的 信息 ， 包 括 符 号 表 、 重 定位 表 等 。 


1. 目 标 文件 


汇编 过 程 的 产物 是 目标 文件 ， 同 前 面 的 预 编译 和 编译 阶段 产生 的 文本 
文件 不 同 ， 目 标 文件 的 格式 更 复杂 ， 其 中 包括 链接 需要 的 信息 ， 所 以 在 理 
解 汇 编 过 程 前 ， 我 们 需要 了 解 一 下 目标 文件 的 格式 。Linux 下 的 二 进 制 文 件 
包括 可 执行 文件 、 静 态 库 和 动态 库 等 ， 均 采用 ELF 格 式 存 储 ， 目 标 文件 的 格 
式 也 不 例外 ， 也 采用 ELEF 格 式 存储 。 


对 于 32 位 的 ELF 文 件 来 说 ， 其 最 前 部 是 文件 头 部 信息 ， 描 述 了 整个 文件 
的 基本 属性 ， 除 了 包括 该 文件 运行 在 什么 操作 系统 中 、 运 行 在 什么 硬件 体 
系 结构 上 、 程 序 入 口 地 址 是 什么 等 基本 信息 外 ， 最 重要 的 是 记录 了 两 个 表 
格 的 相关 信息 ， 如 表格 所 在 的 位 置 、 其 中 包括 的 条 目 数 等 。 这 两 个 表格 一 
个 是 Section Header Table， 主 要 是 供 编译 时 链接 使 用 的 ， 表 格 中 定义 了 各 个 
段 的 位 置 、 长 度 、 属 性 等 信息 ;另外 一 个 是 Program Header Table， 主 要 是 


供 内 核 和 动态 加 载 器 从 磁 副 加 载 ELF 文 件 到 内 存 时 使 用 的 。 对 于 目标 文件 ， 


由 于 其 只 是 编译 过 程 的 一 个 中 间 产 物 ， 不 涉及 装载 运行 


件 中 不 会 创建 Program Header Table 。 


在 后 
区 区 分 


指 的 是 ELF 中 链接 时 使 用 的 Section。 


下 面 我 们 通过 


， 因 此 ， 在 目标 文 


续 内 容 中 ， 我 们 将 Segment 和 Section 都 翻译 为 段 ， 读 者 可 根据 上 下 
。 在 有 的 上 下 文中 ， 段 指 的 是 真正 加 载 到 内 存 中 的 Segment， 而 有 的 


才 命 令 readelf 列 出 目标 文件 foo2.o 的 ELE 头 信息 。 


root@baisheng:~/demo# gcc -c hello.c fool.c foo2.c 


root@baisheng:~/demo# readelf -h foo2.o 


ELF Header: 
Magic: 
Class: 
Data: 
Version: 
OS/ABI: 
ABI Version: 

Type: 

Machine: 

Version: 

Entry point address: 
Start of program headers: 
Start of section headers: 
Flags: 

Size of this header: 

Size of program headers: 


Number of program headers: 


Size of section headers: 


Number of section headers: 
Section header string table index: 


foo2.0 的 ELF 头 占用 了 52 字 节 


件 ， 使 用 "ittle endian" 字 节 序 存储 


行 在 类 UNIX 系 统 上 
， 可 执行 文件 的 类 型 是 


"EXEC(Executable file)", 


7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 


ELF32 

2's complement, 
1 (current) 
UNIX - System V 
0 

REL (Relocatable file) 
Intel 80386 

Oxl1 

0X0 

0 (bytes into file) 
264 (bytes into file) 
0x0 


little endian 


52 (bytes) 
0 (bytes) 
0 
40 (bytes) 
| 
9 
通过 ELEF 头 可 见 该 文件 是 32 位 的 ELE 文 
字 节 ; ABI 遵 循 UNIX-System V 标 准 ; 运 
; 该 文件 是 一 个 "REL(Relocatable file)" 类 型 的 文件 ， 通 


动态 共 享 库 的 类 型 


是 "DYN(Shared object file)"， 静 态 库 和 目标 文件 的 类 型 是 "REL(Relocatable 
file)"; 该 目标 文件 是 为 [A32 架 构 编 译 的 ， 因 为 是 目标 文件 ， 不 存在 执行 的 
概念 ， 所 以 程序 入 口 "Entry point address" 在 这 里 不 适用 (同样 的 道理 ， 

Program Header Table 也 不 适用 ) ; foo2.o 中 的 Section Header Table 在 偏 移 264 


字 节 处 ，S$ection Header Table 中 的 每 个 Section Header 占 用 40 字 节 ，Section 


Header Table 共 包含 12 个 Section Header 。 


在 文件 头 信 息 后 ， 束 是 各 个 段 了 。 吧 不 人 奔 张 地 说 ，ELF 文 件 束 是 段 的 组 
合 。 大 体 上 ， 段 可 以 分 为 如 下 几 类 : 一 类 是 存储 指令 的 ， 通 常 称 为 代码 
段 ， 第 二 类 苹 存 储 数 据 的 ， 通 党 称 为 数据 段 。 但 是 存储 数据 的 又 细 分 为 两 
个 段 ， 已 经 初始 化 的 全 局 数据 存放 在 ".data" 段 中 ， 未 初始 化 的 全 局 数据 存储 
在 ".bss" 段 。 不 要 被 BSS 这 个 令 人 困惑 的 名 称 迷 惑 ， 这 个 名 称 不 是 非常 巾 
切 ， 完 全 是 历史 遗留 的 ，".data" 段 和 ".bss" 段 本 质 并 没有 什么 不 同 ， 但 是 因 
为 未 初始 化 的 变量 不 包含 数据 ， 所 以 在 ELF 文 件 中 不 需要 占用 空间 ， 程 序 装 
载 时 在 内 存 中 即时 分 配 束 可 以 了 。 所 以 ， 为 了 市 省 存储 右 空 间 ， 人 为 地 将 
存储 数据 的 部 分 划分 为 两 个 段 。 除 了 最 重要 的 代码 段 和 数据 段 外 ， 汇 编 占 
还 将 在 目标 文件 中 创建 辅助 链接 段 ， 存 储 如 符号 表 、 重 定位 表 等 。 


我 们 考察 目标 文件 foo2.o 的 Section Header Table， 因 为 排版 篇 幅 的 天 
系 ， 删 除了 后 面 几 列 ， 这 不 影响 我 们 讨论 。 有 兴趣 的 读者 ， 可 以 目 行 查看 


完整 的 命令 输出 。 


root@baisheng:~/demo# readelf -S foo2.o 
There are 12 section headers, starting at offset 0x104 : 


Section Headers: 


[Nr] Name Type Addr OFF Size 

L © NULL 00000000 000000 000000 
bE 1 .EX PROGBITS 00000000 000034 000010 
[2 ereli text REL 00000000 00039c 000008 
LE 3 data PROGBITS 00000000 000044 000004 
[ 4] .bss NOBITS 00000000 000048 000000 
[ 5] .comment PROGBITS 00000000 000048 00002b 
[ 6] .note.GNU-stack PROGBITS 00000000 000073 000000 
[ 7] .eh frame PROGBITS 00000000 000074 000038 
[ 8] .rel.eh frame REDL 00000000 0003a4 000008 
[ 9] .shstrtab STRTAB 00000000 0000ac 000057 
[10] .symtab SYMTAB 00000000 0002e4 0000a0 
L111 “etrtab STRTAB 00000000 000384 000017 


根据 输出 可 见 ， 目 标 文件 foo2.o 的 Section Header Table 中 包含 12 个 


Section Header: 


令 "text" 段 存储 在 文件 中 偏 移 0x34 处 ， 占 据 0x10 个 字 节 。 读 者 不 要 
将 ".text" 段 和 进程 的 代码 段 混 消 ， 进 程 的 代码 段 不 仅 包 括 ".text" 段 ， 在 后 面 
链接 时 ， 我 们 还 会 看 到 ， 包 括 .init 、.fini 等 段 存储 的 代码 都 属于 代码 段 。 
些 段 都 被 映射 到 Program Header Table 中 的 一 个 段 ， 在 ELE 加 载 时 ， 统 一 作为 
进程 的 代码 段 。 


令 ".data" 段 存储 在 文件 中 偏 移 0x44 字 节 人 处， 占据 0x4 字 市 空间 。 


令 如 我 们 在 前 面 讨论 的 ， 虽 然 目 标 文件 的 Section Header Table 中 包 
含 ".bss" 段 ， 但 是 因为 其 不 必 记 录 数 据 ， 所 以 ".bss" 段 在 文件 中 只 占据 Section 
Header Table 中 的 一 个 Section Header， 而 并 没有 对 应 的 段 。 在 加 载 程序 时 ， 
加 载 器 将 依据 ".bss" 段 的 Section Header 中 的 信息 ， 在 内 存 中 为 其 分 配 空间 。 
考察 程序 hello 的 Section Header Table: 


root@baisheng:~/demo# readelf -S hello 
There are 30 section headers, starting at offset 0x1198 : 


Section Headers: 


[Nr] Name Type Addr Off Size 
[25] .bss NOBITS 0804a024 001024 000004 
[26] .comment PROGBITS 00000000 001024 00006b 


根据 输出 可 见 ，".bss" 段 在 文件 中 偏 移 为 0x001024， 但 是 占用 的 空间 
(Size) 并 不 是 0 字 节 ， 而 是 0x4 个 字 世 ， 这 是 为 什么 呢 ? 而 我 们 再 观 
察 ".comment" 段 在 文件 中 的 偶 移 ， 也 为 0x001024。 也 束 是 说 ， 正 如 我 们 前 面 
讨论 的 ，".bss" 段 在 磁盘 文件 中 并 未 占据 任何 空间 ，".bss" 段 的 Size 只 是 告诉 
程序 加 载 器 在 加 载 程序 时 ， 在 内 存 中 为 该 段 分 配 的 内 存 空 间 。 


多 ".Symtab" 段 记录 的 是 符号 表 。 因 为 符号 的 名 字 字 串 长 度 可 变 ， 所 以 
目标 文件 将 符号 的 名 字 字 符 串 剥离 出 来 ， 记 录 在 男 外 一 个 段 ".strtab" 中 ， 符 
号 表 使 用 符号 名 字 的 索引 在 段 ".strtab" 中 的 偏 移 来 确定 符号 的 名 字 。 


全 同样 的 道理 ，".shstrtab" 中 记录 的 是 段 的 名 字 (sh 是 section header 的 简 
写 ) 。 


旬 以 "rel" 开 头 的 ， 如 ".rel.text"、".rel.eh_frame"， 记 杂 的 是 段 中 需要 重 


定位 的 符号 。 


多 ".eh_frame" 段 中 记录 的 是 调试 和 腊 彰 处理 时 用 到 的 信息 。 


令 ".comment"、".note.GNU-stack" 等 段 如 其 名 字 所 示 ， 都 是 一 
些 "comment" 和 "note"， 无 论 是 链接 还 是 装载 都 不 会 用 到 ， 我 们 不 必 关 心 。 


综 上 所 述 ， 目 标 文 件 的 格式 如 图 2-3 所 示 。 


ELF Header 


Section Header 


Table 
图 2-3 目标 文件 
2. 翻 译 机 器 指令 


机 器 指令 由 操作 码 和 操作 数组 成 ， 操 作 码 指 明 该 指令 所 要 完成 的 操 
作 ， 即 指令 的 功能 ， 例 如 数据 传送 、 加 法 运算 等 基本 操作 。 操 作 数 是 参与 
操作 的 数据 ， 主 要 以 寄存 器 或 存储 器 地 址 的 形式 指明 数据 的 来 源 或 者 计算 


结 采 存放 的 位 置 等 。 机 需 指 令 使 用 计算 机 可 以 识别 的 0 和 1 编码 ， 可 想 而 

知 ， 这 对 程序 员 来 说 编码 难度 非常 大 。 因 此 ， 为 了 更 容易 编制 出 程序 ， 就 
出 现 了 汇 纺 指令。 汇编 指 令 非 常 接近 机 器 指令 ， 但 是 机 右 指 令 中 操作 码 和 
操作 数 都 使 用 更 接近 目 然 语言 的 符号 来 代 蔡 ， 这 类 目 然 语言 符号 分 别称 为 
操作 码 助 记 符 和 操作 数 助 记 符 。 人 们 习惯 将 助 记 符 省 略 ， 直 接 将 操作 码 助 
记 符 称 为 操作 码 ， 将 操作 数 助 记 符 称 为 操作 数 ， 读 着 可 根据 上 下 文 区 分 。 


汇编 过 程 束 是 将 助 记 符 翻 译 为 对 应 的 以 0 和 1 表示 的 机 大 指令 ， 我 们 也 
将 其 称 为 操作 码 和 操作 数 的 编码 过 程 。 对 于 IA32 架 构 ， 其 机 器 指令 的 格式 
如 图 2-4 所 示 。 


nstmelion Opcode ModR/M SIB Displacement | Immediate 
Prefixes 
Up to 4 1, 2, or 3 bytes 1 byte 1 byte Address Immediate 
prefixes of opcode (if required) (if required) displacement data of 
1 byte each of 1, 2;.0F4 过 OF 
(optional) \ bytes or none bytes or none 
[4 < 
7 65 32 0 7 65 32 0 
Mod | Reg/ R/M Scale | Index Base 
Opcode 


图 2-4 IA32 机 器 指令 的 格式 


由 图 2-4 可 见 ， 操 作 码 Opcode 直 接 拘 在 指令 中 。 操 作 码 的 翻译 过 程 相对 
简单， 将 汇编 指令 中 的 操作 码 助 记 符 翻译 为 相应 的 操作 码 即 可 ， 操 作 码 助 
记 符 与 操作 码 的 对 应 天 系 可 根据 CPU 的 指令 手册 确定 。 


将 操作 数 助 记 符 翻 译 为 操作 数 的 机 器 码 相 对 要 复杂 一 些 ， 操 作 数 并 没 
有 直接 藤 在 指令 编码 中 ， 而 是 根据 汇编 指令 使 用 的 具体 寻 址 方式 ， 设 置 
ModR/M、SIB、Displacement 和 Immediate 各 项 的 值 ， 这 个 过 程 称 为 操作 数 
的 编码 。CPU 根 据 ModR/M、SIB、Displacement 和 Immediate 的 值 ， 解 码 出 
操作 数 。 


典型 的 操作 数 的 编码 方式 包括 下 面 几 种 。 如 采 读 者 不 太 理 解 下 面 的 抽 
象 搬 述 ， 没 有 关系 ， 后 面 将 结合 具体 的 foo2.c 中 的 函数 foo2_func 探 讨 机 器 指 
令 的 翻译 ， 读 者 可 以 前 后 结合 起 来 理解 。 


(1) 操作 数 地 址 通过 ModR/M 中 的 Mod+R/M 指 定 


ModR/M 占 用 1 字 世 ， 包 合 三 个 域 : Mod、Reg/Opcode 和 R/M， 其 中 Mod 
占 两 位 、R/M 占 3 位 ，Reg/Opcode 占 3 位 。 操 作 数 可 以 使 用 ModR/M 中 的 Mod 
和 R/M 字 有 段 联 合 起 来 定义 ， 寻 址 模式 与 Mod 和 R/M 联 合 编码 的 对 应 关系 如 表 
2-1 所 示 。 


表 2-1 和 寻 址 模式 对 应 的 Mod 和 R/M 联合 编码 
No. Effective Addres R/M 


1 [EAX] 000 


oo 1~1 人 路 | 内 1 人 上 1 


[EAX]+disp8 


( 续 ) 


; 
i 
TE 


LS EAX/AX/AL/MMO/XMMO 


芝 
© 
[= 

(sd . SS 

一 : 一 

© 
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其 中 第 2 列表 示 寻 址 方式 生成 的 有 效 地 址 ; 第 3 列 和 第 4 列表 示 对 应 于 某 
个 寻 址 方式 ，Mod 和 R/M 分 别 对 应 的 编码 。 表 2-1 中 列 出 了 包含 直接 寻 址 、 
寄存 器 寻 址 、 寄 存 器 间接 寻 址 、 基 址 寻 址 及 基 址 变 址 寻 址 等 寻 址 方式 下 
ModR/M 中 Mod 和 R/M 的 对 应 的 编码 。 如 条 汇编 指令 使 用 的 是 基 址 变 址 寻 
址 ， 那 么 机 器 指令 中 也 需要 字段 SIB 。 


以 表 2-1 中 第 7 行为 例 ， 假 设 汇 编 指令 使 用 的 寻 址 方式 是 " 
[EAX]+disp8"， 那 么 Mod 应 该 取 值 01，R/M 应 该 取 值 000。 偏 移 disp8 表 示 8 位 
的 Displacement， 根 据 机 器 指令 的 格式 ，Displacement 直 接 肉 在 指令 中 即 
可 。Displacement 根 据 表示 的 值 的 范围 可 以 使 用 8 位 、16 位 或 者 32 位 ， 这 主 
要 是 出 于 尺寸 方面 的 考虑 。 另 外 ， 在 机 器 指令 中 ，Displacement 需 要 使 用 补 
码 形式 。 也 就 是 说 ， 在 CPU 执行 指令 时 ， 当 解析 到 ModR/M 这 个 字 节 时 ， 一 
旦 发 现 Mod 的 值 是 01，R/M 的 值 是 000， 那 么 CPU 就 到 寄存 器 EAX 中 取出 其 
中 的 内 容 ， 然 后 再 取出 蔡 在 指令 中 的 8 位 的 偏 移 Displacement， 将 这 两 个 值 
相 加 作为 操作 数 的 内 存 地 址 ， 从 而 完成 操作 数 的 解码 过 程 。 


(2) 操作 数 通 过 ModR/M 中 的 Reg/Opcode 指 定 


ModR/M 中 的 字段 Reg/Opcode 占 据 3 位 。 如 果 在 汇编 指令 中 使 用 了 寄存 
器 作为 操作 数 ， 那 么 编码 时 也 可 以 使 用 Reg/Opcode 指 定 操 作 数 使 用 的 寄存 
器 。 如 果 操 作 数 不 需 要 使 用 字段 Reg/Opcode 编 码 ， 字 段 Reg/Opcode 也 可 以 
用 于 操作 码 的 编码 。 表 2-2 列 出 了 32 位 寄存 器 与 字段 Reg/Opcode 取 值 的 对 应 
关系 。 


表 2-2 32 位 寄存 器 对 应 的 Reg/Opcode 的 编码 


egister 


(3) 操作 数 地 址 直接 嵌入 在 机 器 指令 中 


如 采 在 汇编 指令 中 直接 使 用 了 操作 数 的 地 址 ， 即 所 谓 的 直接 寻 址 方 
式 ， 那 么 在 翻译 为 机 融 指 令 时 ， 直 接 使 用 机 需 指 令 中 的 Displacement 字 段 表 
示 操 作 数 的 地 址 。 


(4) 操作 数 直 接 嵌 入 在 指令 中 


如 采 在 汇编 指令 中 ， 操 作 数 吏 是 参与 计算 的 数据 ， 即 所 谓 的 立即 寻 
址 ， 那 么 在 翻译 为 机 器 指令 时 ， 直 接 使 用 机 器 指令 中 的 Immediate 字 上 段 表 示 
操作 数 。 


(5) 操作 数 隐 舍 在 Opcode 中 


还 有 一 种 方式 ， 保 存 操作 数 的 寄存 絮 直 接 隐 全 在 操作 码 Opcode 中 ， 即 
所 谓 的 隐 舍 寻 址 。 


根据 图 2-4 可 见 ， 除 了 操作 码 和 操作 数 外 ， 还 有 一 项 "Instruction 
Prefixes"。 很 难 用 一 段 话 准确 地 描述 "Instruction Prefixes"， 我 们 可 以 打 个 比 
方 : "Instruction Prefixes" 对 于 机 器 指令 类 似 于 "Modifier key" 对 于 键盘 上 的 按 
键 。Shift 键 作为 键盘 上 的 "Modifier key" 之 一 ， 如 对 于 数字 键 3， 当 同时 按 下 
Shift 键 时 ， 其 值 就 变 为 了 符号 “#”。 如 同 Shift 键 只 对 键盘 上 的 某 些 键 有 修饰 
作用 一 样 ，"Instruction Prefixes" 也 只 对 部 分 指令 有 效 。 


比如 对 于 下 面 的 两 类 指令 ， 它 们 的 功能 相同 ， 都 是 在 两 个 操作 数 之 间 
传递 数据 。 只 不 过 第 一 类 是 在 两 个 16 位 操作 数 之 间 传 递 数据 ， 第 二 类 是 在 
两 个 32 位 操作 数 之 间 传 递 数据 。 


mov r/m16,r16 
mov r/m32,r32 


Itel 并 没有 为 上 述 两 类 操作 分 别 定义 两 个 操作 码 ， 而 是 使 用 了 同一 个 损 
作 码 ， 但 是 使 用 Instruction Prefixes 区 分 指令 中 的 操作 数 是 16 位 的 还 是 32 位 
的 。 比 如 在 32 位 环境 下 使 用 了 16 位 的 操作 数 ， 那 么 就 需要 在 指令 前 使 用 
0x66 进 行 标识 。 


以 下 面 的 汇编 代码 为 例 ， 汇 编 文件 a.s 中 的 第 一 条 汇编 代码 使 用 了 16 位 
的 寄存 右 ， 第 二 条 汇编 代码 在 32 位 寄存 右 间 传递 数据 。 


已 。 乌 。 


mOV %ax, %bx 
mOV %eax, Sebx 


将 a.s 编 译 为 目标 文件 ， 并 查看 对 应 的 机 絮 指 令 : 


root@baisheng:~/demo# gcc -c a.s 
root@baisheng:~/demo# objdump -d a.o 
a.o: file format elf32-i386 


Disassembly of section .text: 


00000000 <.text>: 
0: 66 89 c3 mov Sax, Sbx 
3: 89 c3 mov Seax, Sebx 


我 们 观察 第 一 条 指令 和 第 二 条 指令 的 区 别 ， 因 为 笔者 使 用 的 是 32 位 的 
计算 环境 ， 所 以 第 一 条 指令 多 了 前 级 0x66。 也 束 是 说 ， 在 使 用 32 位 操作 数 
的 环境 下 ， 对 于 使 用 了 16 位 操作 数 的 机 器 指令 ， 指 令 前 面 需 要 加 上 前 级 
0x66° 


Intel 规 定 了 四 组 指令 前 级 : Lock and repeat prefixes 、Segment override 
prefixes 和 Branchhints、Operand-size override prefix， 以 及 Address-size 
override prefix。 前 面 我 们 讨论 的 是 Operand-size override prefix， 其 他 几 个 不 
在 这 里 讨论 了 ， 有 需要 的 读者 可 以 参考 Intel 手 册 。 


在 基本 理解 了 从 汇编 指令 翻译 为 机 姨 指 令 的 原理 后 ， 下 面 我 们 束 结 合 
foo2_func 中 的 两 条 汇编 指令 具体 探讨 一 下 将 汇编 指令 翻译 为 机 融 指 令 的 过 
程 。 


movl foo2 ， $%eax 
movl Seax, -4 (Sebp) 


这 两 条 指令 使 用 的 都 是 mov 指 令 ，IA-32 架 构 的 mov 指 令 说 明 如 表 2-3 所 
示 ， 限 于 篇 幅 ， 我 们 仅 列 出 了 部 分 。 表 2-3 中 有 两 列 需 要 特别 关注 ， 一 列 
是 "Opcode"， 这 个 无 需 解释 了 ， 指 令 对 应 的 操作 码 ; 另外 一 列 
是 "Op/En"，"OPp/En" 是 "Operand/Encoding" 的 简写 ， 根 据 列 的 名 称 相信 读者 
已 经 猜 出 来 了 ， 该 列表 示 操 作 数 的 编码 方式 。 


表 2-3 mov 指令 参考 (部分) 


En 

6 | AL [| MovAXmoffsl6 | c | Move word at (seg:offset) to AX. 

7 | AL | MovEAXmoffs32 | c | Move doubleword at (seg:offset) to EAX. 
EE EE EE 

9 | Bstrd | Movezimm32 | E | Move imm32 to r32. 

a RE 


我 们 看 到 ， 对 于 MOV 指 令 ， 不 仅仅 只 有 一 个 操作 码 。 对 于 同一 类 操 
作 ， 可 能 使 用 不 同 的 操作 数 ， 操 作 数 可 能 是 寄存 串 ， 也 可 能 是 内 存 地 址 ， 
同时 操作 数 还 会 有 长 度 之 分 ， 比 如 8 位 、16 位 或 者 32 位 。Intel 采 取 的 策略 是 
为 同一 类 指令 设计 了 多 个 操作 码 来 细 分 这 些 指令 。 比 如 下 面 一 段 代码 : 


二 了 


void malinl() 


{ 


char x, as 


Lit ww: DS 
X = a; 
y = b; 


我 们 编译 并 考察 其 机 器 指令 : 
可 CE =C ‘aa 
objdump -d a.o 
人 file format elf32-i386 
Disassembly of section .text: 


00000000 <main>: 


0: 55 push Sebp 

1 89 e5 mov Sesp, Sebp 

3 83 ec 10 sub $0Ox10,%esp 

6: 0f bp6 45 f6 moOVZP1 -0xa(%Sebp), Seax 
a: 88 45 f7 mov %al, -0x9 ($ebp) 
d: 8b 45 £8 mov -0x8 (Sebp) ,Seax 
fi B89 Sf mov Seax, -0x4 (Sebp) 
1T3s &9 leave 

14: &3 ret 


根据 反 汇 编 的 输出 可 见 ， 两 条 赋值 语句 ， 对 应 都 是 汇编 中 的 MOV 指 
令 。 但 是 ， 对 于 语句 "x=a"， 即 偏 移 a 处 ， 因 为 操作 数 是 8 位 的 ， 所 以 对 应 的 
机 器 码 是 0x88， 也 就 是 表 2-3 中 的 第 1 行 。 对 于 语句 "y=b"， 对 应 偏 移 0x10 
处 ， 因 为 操作 数 是 32 位 的 ， 所 以 机 器 码 用 的 是 0x89， 即 表 2-3 中 的 第 4 行 。 


表 2-3 中 值得 关注 的 另外 一 列 "Op/En" 指 明了 对 应 一 个 指令 的 操作 数 的 编 
码 方式 。 每 一 类 指令 都 有 目 己 的 操作 数 编码 方式 ， 对 于 MOV 指 令 ， 其 操作 
数 的 编码 方式 有 6 类 ， 分 别 用 A~F 来 代表 ， 如 表 2-4 所 示 。 


表 2-4 MOV 指令 的 操作 数 编码 说 明 


F 


NA 


NA 


根据 表 2-4 可 见 ， 如 果 采 用 A 类 编码 方式 ， 第 一 个 操作 数 使 用 ModRM 中 
的 R/M 指 明 ， 第 二 个 操作 数 使 用 ModRM 中 的 Reg/Opcode 指 明 。 如 果 使 用 B 
类 编码 方式 ， 恰 恰 相 反 ， 第 二 个 操作 数 使 用 ModRM 中 的 R/M 指 明 ， 第 一 个 
操作 数 使 用 ModRM 中 的 Reg/Opcode 指 明 。 


看 过 了 MOV 指 令 的 基本 说 明 后 ， 我 们 来 讨论 如 下 指令 
movl foo2, Seax 


这 里 需要 特别 注意 一 点 ， 编 译 句 生成 的 汇编 代码 使 用 的 是 AT&&T 的 格 
式 ， 其 操作 数 的 顺序 与 ntel 的 汇编 指令 正好 相反 ， 所 以 这 条 指令 中 的 第 一 个 
操作 数 "foo2" 是 Intel 语 法 中 的 第 二 个 操作 数 ， 这 条 指令 中 的 第 二 个 操作 
数 "%eax" 和 是 intel 语法 中 的 第 一 个 操作 数 。 


根据 这 条 指令 的 两 个 操作 数 ， 参 照 表 2-3， 匹 配 表 中 的 第 7 行 ， 即 "MOV 
EAX,moffs32"， 根 据 该 行 指令 的 说 明 ， 操 作 码 0xA1 隐 含 地 指出 了 指令 中 的 


第 一 个 操作 数 是 寄存 右 EAX， 也 束 是 寻 址 方式 中 所 谓 的 操作 数 隐 人 台 寻 址 。 


根据 表 2-3 的 "Op/En" 列 可 见 ， 该 指令 的 操作 数 的 编码 方式 是 C， 人 参考 表 
2-4 可 见 ，C 类 编码 方式 并 不 需要 ModR/M， 当 然 也 不 需要 SIB 了 ， 而 且 也 没 
有 使 用 立即 数 作 为 操作 数 ， 亦 不 需要 特殊 的 指令 前 缀 进行 修饰 。 而 且 ， 第 
一 个 操作 数 寄存 器 EAX 是 通过 操作 码 隐 含 指明 。 所 以 ， 该 条 汇编 代码 最 后 


转换 为 如 下 形式 的 机 右 指 令 : 


Opcode + Displacement 


第 二 个 操作 数 "foo2" 通 过 Displacement 表 示 。 这 里 ， 因 为 还 没有 链接 ， 
foo2 的 地 址 尚未 确定 ， 所 以 暂时 填充 0 占 位 ， 在 链接 时 将 根据 实际 地 址 修 
改 。 因 为 是 运行 在 32 位 环境 下 ， 所 以 地 址 是 32 位 的 ，Displacement 占 用 4 字 
节 。 综 上 所 述 ， 该 指令 的 机 融 码 翻译 为 : 


如 相信 丰 让 起 令 0 
再 来 看 指令 : 
mOV Seax, -0X4 (Sebp) 


根据 这 条 指令 的 两 个 操作 数 ， 参 照 表 2-3 可 见 ， 该 指令 匹配 表 中 的 第 4 
行 ， 即 "MOV wm32,r32"， 该 指令 的 操作 码 为 0x89。 在 确定 了 操作 码 后 ， 我 
们 再 来 看 操作 数 的 编码 方式 ， 根 据 表 2-3 中 该 指令 的 列 "Op/En" 可 见 ， 该 指令 
使 用 了 A 类 操作 数 编码 方式 。 根 据 表 2-4 可 见 ，A 类 编码 中 的 第 一 个 操作 数 由 


ModR/M 中 的 Mod 和 R/M 共 同 指 明 ， 第 二 个 操作 数 由 ModR/M 中 的 


Reg/Opcode 指 明 。 


站 令 的 第 一 个 操作 数 "-0x4(%ebp)"， 相 当 于 [EBP]+disp8， 这 里 
Displacement 为 什么 用 8 位 ， 而 不 是 32 位 呢 ? 因 为 对 于 -4， 用 1 字 节 表示 足够 
了 ， 使 用 4 字 节 只 能 徒 增 二 进 制 文件 的 尺寸 。 根 据 A 类 编码 方式 的 要 求 ， 第 
一 个 操作 数 使 用 的 寄存 器 需要 由 ModR/M 中 的 Mod 和 R/M 共 同 指明 ， 参 照 表 
2-1， 根 据 寻 址 模式 可 匹配 第 10 行 ， 该 行 中 Mod 为 01，R/M 为 101， 且 第 一 个 
操作 数 中 的 偏 移 -4 由 Displacement 表 示 ， 在 机 器 指令 中 需要 使 用 数 的 补 码 形 
式 ，-4 的 补 码 为 fc 。 


根据 A 类 编码 方式 的 要 求 ， 第 二 个 操作 数 由 ModR/M 中 的 Reg/Opcode 指 
明 。 汇 编 指令 的 第 二 个 操作 数 使 用 的 寄存 右 是 EAX， 对 照 表 2-2， 寄 存 器 
EAX 对 应 的 Reg/Opcode 值 为 000 。 


综 上 所 述 ， 该 汇编 指令 对 应 的 机 器 编码 格式 为 ， 


Opcode + ModR/M + Displacement 


其 中 Opcode 为 0x89，ModR/M 的 二 进 制 值 为 01 000 101， 用 十 六 进 制 表 
示 为 0x45，Displacement 为 fc， 该 汇编 代码 的 机 需 编 码 为 : 


8 有 过 5 和 有 


至 此 ， 我 们 通过 foo2_func 中 的 赋值 语句 讨论 了 汇编 指令 到 机 器 指令 的 
翻译 过 程 。 相 信 读 者 对 机 器 指令 (包括 汇编 指令 ) 已 经 有 了 更 好 的 理解 。 


我 们 来 查看 一 下 目标 文件 foo2.o 中 这 两 条 汇编 指令 对 应 的 真正 的 机 需 指 


root@baisheng:~/demo# objdump -d foo2.o 
foO02sG file format elf32-i386 
Disassembly of section .text: 


00000000 <foo02 func>: 


0: SS push Sebp 

I 89 e5 mov Sesp, Sebp 

3: 83 ec 10 sub $0x10,%esp 

6: al 00 00 00 00 mov 0x0, Seax 

b: 89 45 fc mOV 当 eaX, -0X4 (Sebp) 
e: c9 leave 

上 : SS ret 


其 中 俩 移 地 址 0x6 和 0xb 处 ， 吏 是 我 们 前 面 讨论 的 两 条 汇编 指令 。 根 据 
输出 可 见 ， 与 我 们 的 讨论 结 采 完全 吻合 。 


objdump 的 输出 是 经 过 加 工 的 ， 我 们 使 用 工具 hexdump 原 汁 原味 地 将 目 
标 文 件 foo2.o 转 存 (dump) 出 来 ， 查 看 其 代码 段 部 分 和 数据 段 部 分 。 我 们 使 
用 了 更 精确 的 参数 控制 hexdump 的 输出 ，"%04_ax" 表 示 使 用 4 位 十 六 进 制 显 
示 侦 移 ; “16/1” 表 示 每 行 显示 16 字 节 ， 逐 字 市 解析 ; "%02x" 表 示 以 十 六 进 制 
显示 ， 每 个 字符 占据 两 位 。 为 了 方便， 读者 使 用 参数 "-C" 即 本。 总之， 要 控 
制 hexdump 逐 个 字 市 解析 ， 避 人 免 hexdump 以 双 字 节 为 单位 进行 解析 ， 并 有 旦 避 
免 使 用 little-endian 进 行 显示 可 能 给 读者 造成 的 困惑 。 下 面 是 我 们 截取 的 
fo02.0 的 ".text" 段 和 ".data" 段 的 厂 段 : 


root@baisheng:~/demo# hexdump -e '"%04 ax:" 16/1 " %02x" "\n"' foo2.o 
O000 7£ WMS: We A6 O01L O01 ‘0L 100 00 09 100 100 100 0 100 100 
O00L0s 01 00 03 O00 01 :00 00 O00 00 00 00 00 00 00 00 00 
0020% be O00 00 100 00 )00 00 100 3 本 O00 .00 00 00 00 28 00 
0030: 0a 00 07 00 55 89 e5 83 ec 10 a1i 00 00 00 00 89 
0040: 45 fc c9 c3 14 00 00 00 00 47 43 43 3a 20 28 55 


其 中 起 始 于 偏 移 0x34 处 、 占 据 0x10 字 节 的 加 粗 斜 体 部 分 正 是 objdump 输 
出 的 foo2_func 的 机 器 指令 。 


注意 起 始 于 偏 移 0x44 字 节 处 、 占 据 0x4 字 节 空间 的 下 划 线 标识 的 4 字 
节 。 注 意 ，IA32 架 构 上 ， 数 据 是 按照 ]ittle-endian 顺 序 存放 的 ， 所 以 这 4 字 节 
表示 的 数据 是 0x14， 而 不 是 0x14000000。 十 六 进 制 的 0x14 正 好 是 foo2.c 中 的 
全 局 变量 foo2 的 初始 值 20。 


这 里 转 存 出 的 ".text" 段 和 ".data" 段 的 信息 与 foo2.o 中 的 Section Header 
Table 中 输出 的 关于 "text" 段 和 ".data" 段 的 信息 也 完全 吻合 ， 即 ".text" 段 起 始 
于 0x34， 占 据 0x10 字 节 ; ".data" 段 起 始 于 0x44， 占 据 0x4 字 方 。f002.0 的 
Section Header Table 中 关于 这 两 个 段 的 信息 如 下 : 


root@baisheng:~/demo# readelf -S foo2.0 
There are 12 section headers, starting at offset 0x104: 


Section Headers: 


[Nr] Name Type Addr 本 下 下 Size 
FE et PROGBITS 00000000 000034 000010 
[ 3] .data PROGBITS 00000000 000044 000004 


在 进行 汇编 时 ， 在 一 个 模块 (这 里 我 们 将 一 个 .c 文 件 称 为 一 个 模块 ) 
内 ， 如 有 果 引 用 了 其 他 模块 或 库 中 的 变量 或 者 钞 数 ， 沪 编 器 并 不 会 解析 引用 
的 外 部 符号 。 因 为 在 汇编 时 ， 模 块 是 独立 编译 的 ， 所 以 对 于 引用 的 外 部 的 
符号 一 无 所 知 。 而 且 退 一 步 说 ， 在 汇编 时 并 没有 为 符号 分 配 运行 时 地 址 
(行文 中 有 时 也 称 为 虚拟 地 址 ) ， 所 以 即使 汇编 器 找到 了 这 些 符号 ， 也 没 
有 任何 意义 ， 这 些 符号 的 地 址 只 是 临时 的 ， 在 进行 链接 时 链接 器 才 会 为 这 


些 符号 分 配 运 行 时 地 址 。 


因此 ， 在 目标 文件 的 机 右 指 令 中 ， 汇 编 器 基本 上 古 留 “ 空 ”引用 的 外 部 
符号 的 地 址 。 然 后 ， 在 链接 时 ， 在 符号 地 址 确定 后 ， 链 接 器 再 来 修订 这 些 
位 置 ， 这 个 修订 过 程 被 称 为 重 定 位 。 当 然 除了 编译 时 重 定位 ， 还 有 加 载 和 
运行 时 重 定位 ， 本 章 讨论 前 者 ， 我 们 在 第 5 章 讨论 后 者 。 事 实 上， 为 了 辅助 


链接 器 在 链接 时 计算 修订 值 ， 这 些 需 要 修订 的 位 置 并 不 是 全 部 都 置 为 0， 有 
时 这 里 填充 的 是 一 个 Addend， 这 束 是 之 所 以 使 用 引号 将 空 引 用 起 来 的 原 
。 下面 我 们 将 会 看 到 这 个 Addend 。 


但 是 链接 器 并 不 能 聪明 到 可 以 目 动 找到 目标 文件 中 引用 外 部 符号 的 地 
方 ， 所 以 在 目标 文件 中 需要 建立 一 个 表格 ， 这 个 表格 中 的 每 一 条 记录 对 应 
的 就 是 一 个 需要 重 定位 的 符号 ， 这 个 表格 通常 称 为 重 定位 表 ， 汇 编 右 将 为 
可 重 定位 文件 中 每 个 包含 需要 重 定位 符号 的 段 都 建立 一 个 重 定位 表 。ELF 标 
准 规定 ， 重 定位 表 中 的 表 项 可 以 使 用 如 下 两 种 格式 : 


glibc-2.15/elf/elf.h: 
typedef struct 
Elf32_Addr rr OFffeet 


Elf32 Word x nfs 
} Elf32 Rel; 


Wg 


* Address */ 
* Relocation type and symbol index */ 


os 


typedef struct 
{ 


Elf32 Addr Y Ofteets 

Elf32 Word EE 

Elf32_Sword r_addend; 
} Elf32 Rela; 


~ 


* Address */ 
* Relocation type and symbol index */ 
* Addend */ 


a es 


这 两 种 格式 唯一 的 不 同 是 成 员 r_addend。 这 个 成 员 一 般 是 个 常量 ， 用 来 
辅助 计算 修订 值 。 如 有 果 使 用 了 第 一 种 格式 ， 那 么 r_addend 将 被 填充 在 引用 外 
部 符号 的 地 址 处 ， 也 惑 是 前 面 所 说 的 留 “ 空 "处 。 具 体 的 体系 结构 可 以 选择 
适合 目 己 的 一 种 格式 ， 或 者 两 种 格式 都 使 用 ， 只 不 过 在 不 同 的 上 下 文中 使 
用 更 合适 的 格式 。IA32 主 要 使 用 了 前 者 ,但 是 也 在 个 别 的 情况 下 了 使 用 了 
= 


r_offset 为 需要 重 定 位 的 符号 在 目标 文件 中 的 偏 移 。 需 要 注意 的 是 ， 对 
于 目标 文件 与 可 执行 文件 或 者 动态 库 ， 这 个 值 是 不 同 的 。 对 于 目标 文件 ， 
r_offset 是 相对 于 段 的 ， 是 段 内 偏 移 ， 而 对 于 可 执行 文件 或 者 动态 库 ， 
r_offset 是 虚拟 地 址 。 


r_info 中 包含 重 定 位 类 型 和 此 处 引用 的 外 部 符号 在 符号 表 中 的 索引 。 根 
据 符 号 在 符号 表 中 的 索引 ， 链 接 郁 吏 可 以 从 符号 表 中 解析 出 符 吕 的 地 址 。 
因为 指令 中 包含 多 种 不 同 的 寻 址 方式 ， 并 且 还 要 针对 不 同 的 情况 ， 所 以 有 
多 种 不 同 的 重 定位 类 型 。 不 同 的 重 定位 类 型 ， 重 定位 的 方法 也 不 同 。 在 
2.1.4 广 中 讨论 “符号 重 定位 ”时 ， 我 们 将 讨论 编译 时 使 用 的 典型 的 重 定位 类 


型 ， 包 括 R_386_32 和 R_386_PC32。 在 第 5 章 讨论 动态 重 定位 时 ， 我 们 将 讨 
论 加 载 和 运行 时 使 用 的 典型 的 重 定位 类 型 R_386_GLOB_DAT 和 


R_386_JMP_SLOT 等 。 


了 解 了 重 定位 的 基本 理论 后 ， 下 面 我 们 来 看 一 下 具体 的 实例 。 使 用 工 
具 readelf 查 看 目标 文件 hello.o 的 重 定位 表 : 


root@baisheng:~/demo# readelf -r hello.o 


Relocation section '.rel.text' at offset 0x3c4 contains 2 entries: 


Offset Info Type Sym.Value Sym. Name 
0000000b 00000901 R 386 32 00000000 foo2 
0000001b 00000a02 R 386_PC32 00000000 foo2_func 


Relocation section '.rel.eh frame' at offset 0x3d4 contains 1 entries: 
Offset Info Type Sym.Value Sym. Name 
00000020 00000202 R 386_PC32 00000000 ‘text 


根据 输出 可 见 ，hello.o 中 ".text" 段 和 ".eh_frame" 段 中 都 有 符号 需要 重 定 
位 ， 所 以 建立 了 两 重 定位 表 。 


在 "text" 段 的 重 定位 表 中 ， 我 们 看 到 ， 目 标 文件 hello.o 引 用 的 外 部 符号 
foo2 和 foo2_func 分 别 占据 表 中 的 第 一 条 和 第 二 条 重 定位 记录 “。 根 据 前 面目 
标 文 件 hello.o 的 反 汇 编 结 末 ，foo2 在 俩 移 0xb 处 ，foo2_func 在 俩 移 0xlb 处 ， 
与 这 里 的 输出 完全 一 致 。 


看 过 重 定位 表 后 ， 我 们 再 来 看 看 汇编 器 在 目标 文件 hello.o 中 引用 符号 
foo2 和 foo2_func 处 填充 的 Addend 是 什么 。 我 们 使 用 工具 objdump 查 看 日 标 文 
件 hello.o: 


root@baisheng:~/demo# objdump -d hello.o 
hello.o: file format elf32-i386 
Disassembly of section .text: 


00000000 <main>: 


0: S55 push Sebp 
Ls 89 e5 mOV Sesp, Sebp 
3: 83 e4 f£0 and $Oxfffffff0,%esp 
6: 83 ec 10 sub $0x10, Sesp 
9: c7 05 00 00 00 00 05 movl $0Ox5, Ox0 
LT0% 00 00 00 
下 总 于 了 说 本 24 D2 00F 0 00 movl $0x32, (Sesp) 
la: es fe ff ££ ££ call lb <main+0xlb> 
C9 leave 
240 人。 人 3 ret 


根据 objdump 的 输出 可 见 : 


在 偏 移 0xb 处 ， 对 应 的 就 是 变量 foo2 的 地 址 ， 汇 编 器 填充 的 Addend 是 


S 在 偏 移 0x1b 处 ， 对 应 的 是 函数 fo02_func 的 地 址 ， 汇 编 器 填充 的 
Addend 是 "fcffffff"， 因 为 I[A32 使 用 的 是 little-endian 字 节 序 ， 补 码 "fffffffc" 对 
应 的 原 码 是 4。 


在 引用 符号 foo2 的 位 置 ， 填 充 0 是 比较 容易 理解 的 ， 链 接 器 只 需要 找到 
从 号 foo2 的 运行 时 地 址 礁 换 这 里 的 0 束 好 了 。 但 是 在 引用 符号 foo2_func 的 位 
置 ， 为 什么 使 用 -4 呢 ， 这 究竟 是 一 个 什么 魔 数 ? 我 们 在 2.1.4 节 中 讨论 “符号 
重 定位 ?时 ， 再 讨论 这 个 -4 的 由 来 。 


4. 符 号 表 


既然 在 链接 时 ， 需 要 重 定位 目标 文件 中 引用 的 外 部 符号 ， 显 然 ， 链 接 
磺 需 要 知道 这 些 符 号 的 定义 在 哪里 ， 为 此 汇编 融 在 每 个 目标 文件 中 创建 了 
个 符号 表 ， 符 号 表 中 记录 了 这 个 模块 定义 的 可 以 提供 给 其 他 模块 引用 的 


root@baisheng:~/demo# readelf -s foo2.o 


Symbol table '.symtab' contains 10 entries: 


Num: Value Size Type Bind Vis Ndx Name 
0: 00000000 0 NOTYPE LOCAL DEFAULT UND 
1: 00000000 0 FILE LOCAL DEFAULT ABS foo2.c 
2: 00000000 0 SECTION LOCAL DEFAULT 下 
3: 00000000 0 SECTION LOCAL DEFAULT 3 
4: 00000000 0 SECTION LOCAL DEFAULT 4 
5: 00000000 0 SECTION LOCAL DEFAULT 6 
6: 00000000 0 SECTION LOCAL DEFAULT 7 
7: 00000000 0 SECTION LOCAL DEFAULT 5 
8: 00000000 4 OBJECT GLOBAL DEFAULT 3 EQ62 
9: 00000000 16 FUNC GLOBAL DEFAULT 二 E062, fune 


根据 输出 可 见 ，foo2.o 符 号 表 包 含 10 个 符号 。Value 列 表示 的 是 符号 的 地 
址 。 前面 我 们 提 到 ， 链 接 时 链接 器 才 会 为 符号 分 配 地 址 ， 所 以 我 们 看 到 的 
符号 的 地 址 全 部 是 0。Size 列 表示 符号 对 应 的 实体 占据 的 内 存 大 小 ， 如 变量 
foo2 占 据 4 字 节 ， 函 数 fo02_func 占 据 16 字 节 。Type 列 表示 符号 的 类 型 ， 如 
fo0o2 类 型 为 OBJECT， 表 示 变 量 ，foo02_func 类 型 为 FUNC， 表 示 函 数 。Bind 
列表 示 符 号 绑 定 的 相关 信息 ，LOCAL 表 示 模 块 内 部 符号 ， 对 外 部 不 可 见 ; 
GLOBAL 表示 全 局 符号 ，foo2 和 foo2_func 都 属于 全 局 变量 。Ndx 列 表示 该 符 


号 在 哪个 段 ， 如 foo2 在 第 3 个 段 ， 即 ".data" 段 ，foo2_func 在 第 1 个 段 ， 


即 ".text" 段 。Name 列 表示 符号 的 名 称 。 


除了 模块 定义 的 符号 外 ， 符 号 表 中 也 包括 了 模块 引用 的 外 部 符号 ， 如 
模块 hello 的 符号 表 如 下 : 


root@baisheng:~/demo# readelf -s hello.o 


Symbol table '.symtab' contains 11 entries: 


Num: Value Size Type Bind Vis Ndx Name 
0: 00000000 0 NOTYPE LOCAL DEFAULT UND 
1: 00000000 0 FILE LOCAL DEFAULT ABS hello.c 
2: 00000000 0 SECTION LOCAL DEFAULT 1 
3: 00000000 0 SECTION LOCAL DEFAULT 
4: 00000000 0 SECTION LOCAL DEFAULT 4 
5: 00000000 0 SECTION LOCAL DEFAULT 6 
6: 00000000 0 SECTION LOCAL DEFAULT 7 
7: 00000000 0 SECTION LOCAL DEFAULT 5 
8: 00000000 33 EUNG GLOBAL DEFAULT 1 main 
9: 00000000 0 NOTYPE GLOBAL DEFAULT UND foo2 
10: 00000000 0 NOTYPE GLOBAL DEFAULT UND foo2 func 


符号 foo2 和 foo2_func 都 在 模块 foo2 中 定义 ， 对 于 模块 hello 来 说 是 外 部 符 
号 ， 没 有 在 任何 一 个 段 中 ， 所 以 在 列 Ndx 中 ，foo2 和 foo2_func 的 值 是 UND 。 
UND 是 Undefined 的 缩写 ， 表 示 符 号 foo2、foo2_func 是 未 定义 的 。 


在 链接 时 ， 对 于 模块 中 引用 的 外 部 符号 ， 链 接 器 将 根据 符号 表 进 行 符 
号 的 重 定位 。 如 果 我 们 将 符号 表 删除 了 ， 那 么 链接 占 在 链接 时 将 找 不 到 符 
号 的 定义 ， 从 而 不 能 进行 正确 的 符号 解析 。 如 我 们 将 foo2.o 中 的 符号 表 删 
除 ， 再 次 进行 链接 ， 则 链接 器 将 因 找 不 到 符号 定义 而 终止 链接 ， 如 下 所 


人 小 : 


root@baisheng:~/demo/tmp# strip foo2.o 

root@baisheng:~/demo# gcc -o hello *.o 

/usr/bin/1ld: error in foo2.0(.eh frame); no .eh frame hdr table will be 
hello.o: In function 'main' : 

hello.c: (.text+0xb) : undefined reference to 'foo2' 

hello.c: (.text+0x1b): undefined reference to 'foo0o2 func' 

collect2: error: ld returned 1 exit status 


created. 


pA 


链接 是 编译 过 程 的 最 后 一 个 阶段 ， 链 接 如 将 一 个 或 者 多 个 目标 文件 和 
库 ， 包 括 动态 库 和 静态 库 ， 链 接 为 一 个 单独 的 文件 (通常 为 可 执行 文件 、 
动态 库 或 者 静态 库 ) 。 链 接 器 的 工作 可 以 分 为 两 个 阶段 : 


令 第 一 阶段 是 将 多 个 文件 合并 为 一 个 单独 的 文件 。 对 于 可 执行 文件 ， 
还 需要 为 指令 及 符号 分 配 运 行 时 地 址 。 


令 第 二 阶段 进行 符号 重 定位 。 


工 合并 目标 文件 


合并 多 个 目标 文件 其 实 束 是 将 多 个 目标 文件 的 相同 类 型 的 段 合并 到 一 
个 段 中 ， 如 图 2-5 所 示 。 


Object File 1 


Text Section 


Data Section Text Section 


Text Section 
Data Section 


Data Section 


Object File 2 


Executable 


图 2-5 合并 目标 文件 


我 们 来 看 一 下 目标 文件 和 链接 后 的 可 执行 文件 的 ".text" 段 。 下 面 分 别 列 
出 了 目标 文件 hello.o、foo1.0、foo2.0 以 及 可 执行 文件 hello 的 段 表 中 
的 ".text" 段 的 相关 信息 。 由 于 篇 幅 限 制 ， 我 们 删除 了 输出 的 后 面 儿 列 。 


root@baisheng:~/demo# readelf -S hello.o 
There are 12 section headers, starting at offset 0x118 : 


Section Headers: 


[Nr] Name Type Addr Off Size 
i NULL 00000000 000000 000000 
【 1] stext PROGBITS 00000000 000034 000026 


root@baisheng:~/demo# readelf -S fool.o 
There are 12 section headers, starting at offset 0x104: 


Section Headers: 


[Nr] Name Type Addr Off Size 
[ 0] NULL 00000000 000000 000000 
LL] sext PROGBITS 00000000 000034 000010 


root@baisheng:~/demo# readelf -S foo2.o 
There are 12 section headers, starting at offset Ox104: 


Section Headers: 


[Nr] Name Type Addr Off Size 
[ 0] NULL 00000000 000000 000000 
[ 11] stext PROGBITS 00000000 000034 000010 


root@baisheng:~/demo# readelf -S hello 
There are 30 section headers, starting at offset 0x1198 : 


Section Headers: 
[Nr] Name Type Addr Off Size 


Ls) stext PROGBITS 080482f0 0002f0 0001b8 


根据 上 面 的 输出 结果 可 见 ， 对 于 目标 文件 ， 并 没有 为 目标 文件 中 的 机 
器 指令 及 符号 分 配 运行 时 地 址 。 而 对 于 可 执行 文件 hello， 链 接 器 已 经 为 其 
机 器 指令 及 符号 分 配 了 运行 时 地 址 ， 如 对 于 可 执行 文件 hello 的 ".text" 段 ， 其 
在 进程 地 址 空间 中 起 始 地 址 为 "0x080482f0"， 占 据 了 0x1b8 字 节 。 


按照 前 面 我 们 提 到 的 目标 文件 合并 理论 ， 理 论 上 三 个 目标 文件 hello.o、 
foo1.0、foo02.0 的 ".text" 段 的 尺寸 加 起 来 应 该 与 可 执行 文件 hello 的 ".text" 段 的 
尺寸 大 小 相等 。 但 是 ， 通 过 readelf 的 输出 可 见 ， 三 个 目标 文件 的 ".text" 段 的 
尺寸 加 起 来 是 0x46 (0x26+0x10+0x10) 字 节 ， 远 小 于 可 执行 文件 hello 


的 ".text" 段 的 大 小 0xlb8。 如 采 读 者 在 编译 时 问 gcc 传 递 了 参数 -v， 仔 细 观 察 
gcc 的 输出 可 以 发 现 ， 实 际 上 在 链接 时 链接 右 目 作 主 张 地 链接 了 一 些 特别 的 
文件 ， 包 括 crtl.o、crtio、crtn.o、crtbegin.o 及 crtend.o 等 ， 其 实 就 是 我 们 前 
面 提 到 的 局 动 文件 。 所 以 多 出 来 的 尺寸 部 是 合并 这 些 文件 的 ".text" 导 致 的 。 


下 面 我 们 手动 调用 1d， 不 链接 这 些 启动 文件 ， 再 来 对 比 一 下 ".text" 段 的 
尺寸 。 在 默认 情况 下 ， 链 接 器 将 使 用 函数 "_start" 作 为 可 执行 文件 的 入 口 ， 
但 是 这 个 函数 的 实现 在 启动 文件 (crt1.o) 中 ， 因 此 ， 在 这 里 我 们 通过 给 链 
接 器 ld 传递 参数 "-e main"， 明 确 告诉 链接 器 不 使 用 默认 的 "_start" 了 ， 否 则 链 
接 絮 会 找 不 到 符号 "_start"， 而 直接 使 用 函数 main 作 为 可 执行 文件 的 入 口 。 
当然 main 函 数 中 并 没有 实现 启动 代码 的 功能 ， 在 这 里 我 们 只 是 为 了 查 
看 ".text" 段 的 尺寸 。 具 体 如 下 : 


root@baisheng:~/demo# ld -e main -o hellol hello.o fool.o foo2.o 
root@baisheng:~/demo# readelf -S hellol 
There are 8 section headers, starting at offset Oxlbc: 


Section Headers: 
[Nr] Name Type Addr OfE Size 
[ 0] NULL 00000000 000000 000000 
Bl "ER PROGBITS 08048094 000094 000048 


我 们 看 到 ， 如 采 不 链接 那些 特殊 的 文件 ， 按 照 上 面 的 链接 方法 ， 可 执 
行文 件 的 ".text" 段 的 大 小 是 0x48 字 节 ， 依 然 不 是 0x46 字 季 ， 为 什么 还 是 关 了 
2 字 节 ? 我 们 等 试 更 换 一 下 链接 时 目标 文件 的 次 序 : 


root@baisheng:~/demo# ld -e main -o hello2 fool.o foo2.o hello.o 
root@baisheng:~/demo# readelf -S hello2 
There are 8 section headers, starting at offset Oxlbc: 


Section Headers: 


[Nr] Name Type Addr OEE Size 
上 区] NULL 00000000 000000 000000 
| 1 ex PROGBITS 08048094 000094 000046 


这 次 我 们 看 到 ， 最 终 可 执行 文件 ".text" 段 的 尺寸 与 目标 文件 的 ".text" 段 
的 尺寸 和 完全 相同 了 。 为 什么 呢 ? 原因 是 在 32 位 机 器 上 ， 包 
括 ".text"、".data" 等 段 有 4 字 节 对 齐 的 要 求 。hello.0 的 ".text" 段 是 0x26， 如 果 
按照 4 字 节 对 齐 ， 需 要 填充 2 字 节 。 而 foo1.o 和 foo2.o 的 ".text" 段 本 身长 度 都 是 
4 字 节 对 齐 的 ， 所 以 在 合并 时 ， 如 果 hello.o 在 前 面 ， 那 么 其 ".text" 段 需要 使 用 
0 填充 两 字 节 ， 使 其 对 齐 到 0x28。 所 以 ， 最 终 ".text" 的 长 度 就 是 
0x28+0x10+0x10， 为 0x48 字 节 。 而 如 果 hello 在 最 后 ， 那 么 合并 后 的 ".text" 的 


长 度 就 是 0x10+0x10+0x26， 即 0x46 字 节 。 


链接 时 ， 在 第 一 阶段 完成 后 ， 目 标 文件 已 经 合并 完成 ， 并 且 已 经 为 符 


号 分 配 了 运行 时 地 址 ， 链 接 器 将 进行 符号 重 定位 。 


模块 hello.o 中 有 两 处 需要 重 定位 ， 一 处 是 偏 移 0xb 处 的 变量 foo2， 男 外 
一 处 是 偏 移 0x1b 处 的 函数 fo02_func。 汇 编 器 已 经 将 这 两 处 需要 重 定位 的 符 
号 记录 在 了 重 定 位 表 中 。 


root@baisheng:~/demo# readelf -r hello.o 


Relocation section '.rel.text' at offset 0x3c8 contains 2 entries: 


Offset Info Type Sym.Value Sym. Name 
0000000b 00000901 R 386 32 00000000 foo2 
0000001b 00000a02 R 386 PC32 00000000 £002. fune 


符号 foo2 的 重 定位 类 型 是 R_386_32，ELF 标 准 规 定 的 计算 修订 值 的 公式 


ft 


S + 人 


其 中 ，S 表 示 符 号 的 运行 时 地 址 ，A 就 是 汇编 器 填充 在 引用 外 部 符号 处 
的 Addend 。 


符号 foo2_func 的 重 定位 类 型 是 R_386 PC32，ELEF 标 准 规定 的 计算 修订 
值 的 公式 是 : 


S+A- 了 


其 中 $、A 的 意义 与 前 面 完全 相同 ，P 为 修订 处 的 运行 时 地 址 或 者 偏 移 。 
对 于 目标 文件 ，P 为 修订 处 在 段 内 的 偶 移 。 对 于 可 执行 文件 和 动态 库 ， 了 为 
修订 处 的 运行 时 地 址 。 


首先 我 们 先 来 确定 S。 运 行 时 地 址 在 链接 时 才 分 配 ， 因 此 ， 变 量 foo2 和 
函数 foo2_func 的 运行 时 地 址 在 链接 后 的 可 执行 文件 hello 的 符号 表 中 : 


root@baisheng:~/demo# readelf -s hello | grep foo2 


38: 00000000 0 FILE LOCAL DEFAULT ABS foo2.c 
53: 0804a020 4 OBJECT GLOBAL DEFAULT 24 foo2 
68: 08048414 16 FUNC GLOBAL DEFAULT 13 F002 me 


可 见 ， 符 号 foo2 的 运行 时 地 址 为 0x0804a020， 符 号 foo2_func 的 运行 时 
地 址 是 0x08048414 。 


接 下 来 ， 我 们 再 来 看 看 汇编 器 为 这 两 个 从 号 填充 的 Addend 是 多 少 。 我 
们 使 用 工具 objdump 反 汇编 hello.o， 其 中 黑体 标识 的 分 别 是 汇编 器 在 引用 
foo2 和 foo2_func 的 地 址 处 填充 的 Addend: 


root@baisheng:~/demo# objdump -d hello.o 
hello.o: file format elf32-i386 
Disassembly of section .text: 


00000000 <main>: 


0: SD push Sebp 
1: 89 e5 mov Sesp, Sebp 
3: 83 e4 f0 and SOxfffffff0,s%esp 
6: 83 ec 10 sub $0x10,%esp 
9: c7 05 00 00 00 00 05 movl SOXx5; Ox0 
上 上 00. 00 00 
L135 c7 04 24 32 00 00 00 movl $0Ox32, (Sesp) 
la: en fo LF FE EF call lb <main+0xlb> 
本 下 入 b8 00 00 00 00 mov $0Ox0, Seax 
24: &9 leave 
25's G3 ret 


根据 输出 可 见 ， 汇 编 器 在 引用 符号 foo2 处 填充 的 Addend 是 0， 在 引用 符 
号 foo2_func 处 填充 的 Addend 是 -4。 


于 是 ， 可 执行 文件 hello 中 引用 符号 foo2 的 位 置 的 修订 值 为 : 


S+A = 0x0804a020 + 0 = 0x0804a020 


我 们 反 汇 编 可 执行 文件 hello， 来 验证 一 下 引用 符号 foo2 处 的 值 是 否 修订 
为 我 们 计算 的 这 个 值 : 
root@baisheng:~/demo# objdump -d hello 


hello: file format elf32-i386 


080483dc <main>: 


80483Qcs 55 push Sebp 

80483dd: 89 e5 mov Sesp, Sebp 
80483df: 83 e4 f0 and S$SOxfffffff0,S%esp 
80483e2: 83 ec 10 sub $0x10,%esp 


80483e5:  c7 05 20 a0 04 08 05 movl $0Ox5, Ox804a020 
80483ec: 00 00 00 

80483ef: c7 04 24 32 00 00 00 movl $0Ox32, (Sesp) 
80483f6: ee8 19 00 00 00 call 8048414 


<foo02 func> 


80483fb: b8 00 00 00 00 mOV $0Ox0, Seax 
8048400: c9 leave 

8048401: c3 ret 

8048402: 66 90 Xehg Sax, Sax 


注意 偏 移 0x1b 人 处， 确实 已 经 被 链接 器 修订 为 0x0804a020 了。 


对 于 符号 foo2_func 的 修订 值 ， 还 需要 变量 P， 即 引用 符号 foo2_func 处 的 
运行 时 地 址 。 根 据 可 执行 文件 hello 的 反 汇 编 代 码 可 见 ， 引 用 符号 foo2_func 
的 指令 的 地 址 是 : 


0x80483f6 + 1 = 0x80483f7 


所 以 ， 可 执行 文件 hello 中 引用 符号 foo2_func 的 位 置 的 修订 值 为 : 


S++A-P= 0x08048414 + (=-4) - 0x80483f7 = 0x19 


观察 hello 的 反 汇 编 代 码 ， 从 地 址 0x80483f7 开 始 处 的 4 字 节 ， 确 实 也 已 经 
被 链接 器 修订 为 0x19 。 


这 里 提醒 一 下 读者 ， 如 果 foo2_func 占 据 的 运行 时 地 址 小 于 main 函 数 ， 
那么 这 里 foo2_func 与 PC 的 相对 地 址 将 是 负数 。 在 机 器 指令 中 ， 使 用 的 是 数 
的 补 码 形式 ， 所 以 一 定 要 注意 ， 以 免 造成 困惑 。 


事实 上 ， 对 于 符号 foo2 使 用 的 重 定位 类 型 R_386_32， 是 绝对 地 址 重 定 
位 ， 链 接 器 只 要 解析 符号 foo2 的 运行 时 地 址 替换 修订 处 即 可 。 而 对 于 符号 
foo2_func， 其 使 用 的 重 定位 类 型 是 R_386_PC32， 这 是 一 个 PC 相对 地 址 重 定 
位 。 而 当 执 行当 前 指令 时 ，PC 中 已 经 加 载 了 下 一 条 指令 的 地 址 ， 并 不 是 当 
前 指令 的 地 址 ， 这 就 是 在 引用 符号 foo2_func 处 填充 “-4” 的 原因 。 


我 们 看 到 ， 在 链接 时 ， 链 接 器 在 需要 重 定位 的 符号 所 在 的 偏 移 处 直接 
进行 了 编辑 修订 ， 所 以 人 们 通常 也 将 链接 器 形象 地 称 为 "link editor"。 


如 果 在 链接 过 程 中 有 静态 库 ， 那 么 链接 是 如 何 进行 的 呢 ? 静态 库 其实 
忠 是 多 个 目标 文件 的 打包 ， 因 此 ， 与 合并 多 个 目标 文件 并 无 本 质 差 别 。 但 
征 有 一 点 需要 特别 说 明 ， 在 链接 静态 库 时 ， 并 不 是 将 整个 静态 库 中 包含 的 
目标 文件 全 部 复制 一 份 到 最 终 的 可 执行 文件 中 ， 而 征 仅仅 链接 库 中 使 用 的 


目标 文件 。 如 图 2-6 所 示 ， 在 对 可 执行 文件 链接 时 ， 只 使 用 了 静态 库 中 
的 "Object File 2"， 所 以 链接 器 仅 将 "Object File 2" 复 制 了 一 份 到 可 执行 文件 
中 。 


Text Section 
Object File 1 S 
DataSection | [Se 3 | 
g 
w 
rh) 
wr sec 
又 Text Section 
Text Section Y 
Object File 2 区 Data Section 
Data Section | sa 号 
| 
Se gd 
Un 
| ss Object File 
~ (ae] 
加 
Y 
Object File n i 加 


Static Library Executable 


图 2-6 链接 静态 库 


我 们 使 用 如 下 命令 先 将 fool.c 和 foo2.c 编 译 为 静态 库 libfoo.a。 然 后 将 静 
态 库 libfoo.a 链 接 到 可 执行 程序 hello 。 


root@baisheng:~/demo# gcc -c fool.c foo2.c 
root@baisheng:~/demo# ar -r libfoo.a fool.o foo2.o 
root@baisheng:~/demo# gcc -o hello hello.c libfoo.a 


我 们 来 看 一 下 静态 库 libfoo.a 的 符号 表 : 


root@baisheng:~/demo# readelf -s libfoo.a 


File: libfoo.al(lfool.o) 
Symbol table '.symtab' contains 10 entries: 
Num: Value Size Type Bind Vis Ndx Name 
0: 00000000 0 NOTYPE LOCAL DEFAULT UND 
1: 00000000 0 FILE LOCAL DEFAULT ABS fool.c 
2: 00000000 0 SECTION LOCAL DEFAULT 
3: 00000000 0 SECTION LOCAL DEFAULT 过 
4: 00000000 0 SECTION LOCAL DEFAULT 4 
5: 00000000 0 SECTION LOCAL DEFAULT 6 
6: 00000000 0 SECTION LOCAL DEFAULT 办 
7: 00000000 0 SECTION LOCAL DEFAULT 5 
8: 00000000 4 OBJECT GLOBAL DEFAULT 3 EOGL 
9: 00000000 19 FUNC GLOBAL DEFAULT 1 Fo Fone 
File: libfoo.a (foo2.0) 
Symbol table '.symtab' contains 10 entries: 
Num: Value Size Type Bind Vis Ndx Name 
0: 00000000 0 NOTYPE LOCAL DEFAULT UND 
1: 00000000 0 FILE LOCAL DEFAULT ABS foo2.c 
2: 00000000 0 SECTION LOCAL DEFAULT 1 
3: 00000000 0 SECTION LOCAL DEFAULT 3 
4: 00000000 0 SECTION LOCAL DEFAULT 4 
5: 00000000 0 SECTION LOCAL DEFAULT 6 
6: 00000000 0 SECTION LOCAL DEFAULT 流 
7: 00000000 0 SECTION LOCAL DEFAULT 法 
8: 00000000 4 OBJECT GLOBAL DEFAULT 3 foo2 
9: 00000000 19 FUNC GLOBAL DEFAULT 1 foo2 func 


我 们 看 到 ， 与 代码 中 完全 吻合 ，libfoo.a 的 符号 表 中 包含 4 个 全 局 符号 ， 
分 别 是 变量 foo01 和 foo2、 函 数 fool_func 和 foo2_func。 如 果 最 终 创建 的 可 执行 
文件 hello 包 含 了 整个 libfoo.a 的 副本 ， 那 么 hello 的 符号 表 中 也 应 该 包含 这 4 个 
全 局 符号 。 但 是 ， 实 际 上 hello.c 中 仅 使 用 了 目标 文件 foo2.o 中 的 函数 
foo2_func， 所 以 按照 我 们 前 面 的 理论 ，hello 中 应 该 仅仅 包含 foo2.o 的 副本 ， 
而 不 必 包 含 没有 使 用 的 foo1.0。 我 们 查看 一 下 hello 的 符号 表 : 


root@baisheng:~/demo# readelf -s hello | grep foo 


37: 00000000 0 FILE LOCAL DEFAULT ABS foo2.c 
52: 0804a01c 4 OBJECT GLOBAL DEFAULT 24 foo2 
65: 080483f0 19 FUNC GLOBAL DEFAULT 3 E02 mnie 


以 上 hello 的 符号 表 仅 包含 了 foo2 和 foo2_fiunc， 显 然 ， 可 执行 文件 hello 
中 确实 没有 包含 目标 文件 foo1.o。 至 于 链接 静态 库 中 的 目标 文件 的 方法 ， 与 
我 们 前 面 讨 论 的 目标 文件 的 合并 完全 相同 。 


4. 链 接 动 态 库 


我 们 知道 ， 与 静态 库 不 同 ， 动 态 库 不 会 在 可 执行 文件 中 有 任何 副本 ， 
那么 为 什么 编译 链接 时 依然 需要 指定 动态 库 呢 ? 原因 包括 下 面 儿 点 : 


1) 动态 加 载 器 需要 知道 可 执行 程序 依赖 的 动态 库 ， 这 样 在 加 载 可 执行 
程序 时 才能 加 载 其 依赖 的 动态 库 。 所 以 ， 在 链接 时 ， 链 接 器 将 根据 可 执行 
程序 引用 的 动态 库 中 的 符号 的 情况 在 dynamic 段 中 记录 可 执行 程序 依赖 的 动 
态 库 。 我 们 使 用 如 下 命令 将 foo1.c 和 foo2.c 编 译 为 动态 库 ， 并 将 hello 链 接 到 
动态 库 libfoo.so。 


root@baisheng:~/demo# gcc -shared -fPIC fool.c foo2.c -o libfoo.so 
root@baisheng:~/demo# gcc hello.c -o hello -L./ -lfoo 


我 们 来 查看 hello 中 的 dynamic 段 : 


root@baisheng:~/demo# readelf -d hello | grep Shared 
0x00000001 (NEEDED ) Shared library: [libfoo.so] 
0x00000001 (NEEDED) Shared library: [libc.so.6] 


显然 ， 在 dynamic 段 中 ， 记 录 了 hello 依 赖 的 动态 链接 库 libfoo.so。 


E 


2) 链接 器 需要 在 重 定位 表 中 创建 重 定位 记录 (Relocation Record) ， 
这 样 当 动态 链接 器 加 载 hello 时 ， 将 依据 重 定位 记录 重 定位 hello 引 用 的 这 些 
外 部 符号 。 重 定位 记录 存储 在 ELF 文 件 的 重 定位 段 (Relocation) 中 ，ELF 
文件 中 可 能 有 多 个 段 包 含 需要 重 定位 的 符号 ， 所 以 可 能 会 包含 多 个 重 定位 
段 。 以 hello 的 重 定位 段 为 例 : 


root@baisheng:~/demo# readelf -r hello 


Relocation section '.rel.dyn' at offset 0x3d4 contains 2 entries: 
Offset Info Type Sym.Value Sym. Name 
08049ffc 00000206 R 386 GLOB DAT 00000000 gmon start 
0804a020 00000905 R 386 COPY 0804a020 foo2 


Relocation section '.rel.plt' at offset 0x3e4 contains 3 entries: 


Offset Info Type Sym.Value Sym. Name 
0804a00c 00000207 R 386 JUMP SLOT 00000000  _ gmon start _ 
0804a010 00000307 R 386 JUMP SLOT 00000000 libc start main 


0804a014 00000507 R 386 JUMP SLOT 00000000 fo02 func 


根据 输出 可 见 ， 可 执行 文件 hello 包 含 两 个 重 定位 段 ，".rel.dyn" 段 中 记 和 了 
的 是 加 载 时 需要 重 定位 的 变量 ，".rel.plt" 段 中 记录 的 是 需要 重 定位 的 函数 。 


因此 ， 虽 然 编译 时 不 需要 链接 共享 库 ， 但 是 可 执行 文件 中 需要 记录 其 
依赖 的 共享 库 以 及 加 载 /运行 时 需要 重 定位 的 条 目 ， 在 加 载 程序 时 ， 动 态 加 
载 器 需要 这 些 信息 来 完成 加 载 时 重 定位 。 


后 我 们 再 来 关注 一 下 在 hello 中 的 全 局 符号 foo2 和 foo2_func。 


root@baisheng:~/demo# nm hello | grep foo 
0804a020 B foo2 
UV £9062, fune 


在 符号 表 中 ， 我 们 看 到 ，foo2_func 是 Undefined 的 ， 这 没 错 ， 因 为 其 确 
实 不 在 hello 中 定义 。 但 是 注意 变量 foo2， 理 论 上 它 也 应 该 是 Undefined 的 ， 
但 是 我 们 看 到 其 在 hello 中 是 有 定义 的 ， 而 且 其 还 在 BSS 段 中 。 换 句 话说 ， 吕 
然 我 们 在 hello 中 没有 定义 一 个 未 初始 化 的 全 局 变量 ， 但 是 链接 器 却 偷偷 在 
hello 中 定义 了 一 个 未 初始 化 的 变量 foo2。 那 么 ， 这 个 foo2 与 libfoo.so 中 的 全 
局 变量 foo2 是 什么 关系 呢 ? 为 什么 编译 器 要 这 样 做 ? 这 也 是 和 重 定位 有 关 
的 ， 事实 上 ， ee relocation"， 后 面 我 们 在 讨论 用 户 

进程 的 加 载 时 将 会 介绍 。 


2.2 ”构建 工具 链 


虽然 构建 的 目标 系统 是 运行 在 IA32 体 系 架构 上 的 ， 但 是 我 们 不 能 
使 用 宿主 系统 的 工具 链 ， 否 则 可 能 会 导致 目标 系统 依赖 和 宾主 系统 。 在 
编译 程序 时 ， 如 琳 使 用 了 宿主 系统 的 链接 上 器， 那么 链接 颖 将 在 笨 主 系 
统 的 文件 系统 中 寻找 依赖 的 动态 库 ， 这 势必 会 导致 目标 系统 中 的 程序 
链接 宿主 系统 的 某 些 库 ， 从 而 导致 目标 系统 依赖 宿主 系统 。 其 直观 表 
现 丈 是 程序 在 编译 时 可 能 会 顺利 通过 ， 但 是 当 在 目标 系统 中 运行 时 ， 
却 可 能 出 现 未 定义 符号 的 错误 。 


除了 上 述 的 依赖 问题 外 ， 目 标 系统 使 用 的 工具 链 的 各 个 组 件 的 版 
本 ， 通 浓 不 同 于 御 主 系统 ， 因 此 ， 这 也 要 求 为 目标 系统 构建 一 套 新 的 
工具 链 。 


但 是 工具 链 在 软件 开发 中 占据 极其 重要 的 位 置 ， 包 括 编译 、 汇 
编 、 链 接 等 多 个 组 件 在 内 的 任 一 组 件 的 问题 都 可 能 导致 程序 执行 时 出 
现 问题 ， 如 执行 效率 低下 ， 甚 至 市 来 安全 问题 。 因 此 ， 在 实际 应 用 
中 ， 很 多 时 候 我 们 都 是 直接 使 用 已 经 构建 好 的 工具 链 ， 这 类 工具 链 一 
般 都 被 广 沁 使 用 ， 所 以 在 某 种 意义 上 其 正确 性 是 被 实践 检验 过 的 ， 但 
是 也 有 人 缺 点， 就 是 没有 针对 具体 的 硬件 平台 进行 优化 。 因 此 ， 有 时 我 
们 也 会 借助 某 些 辅助 工具 ， 针 对 我 们 的 特定 硬件 ， 进 行 配置 优化 ,“ 半 
目 动 ”地 为 目 标 系统 构建 编译 工具 链 。 


在 现实 中 ， 完 全 手工 构建 工具 链 的 机 会 并 不 多 ， 很 多 时 候 我 们 可 
能 都 是 使 用 别人 已 经 构建 好 的 。 但 是 ， 工 具 链 中 包含 的 组 件 可 以 说 是 
除了 操作 系统 内 核 之 外 的 最 说 层 的 系统 软件 ， 无 论 是 对 理解 操作 系 
统 ， 还 是 对 开发 程序 来 说 ， 都 有 着 重要 的 意义 。 即 使 永远 不 需 目 己 手 
工 编译 工具 链 ， 但 是 了 解 工 具 链 的 构建 过 程 ， 也 可 以 帮助 更 高 效 灵活 
地 运用 已 有 的 工具 链 ， 可 以 在 多 个 现成 的 工具 链 中 进行 更 好 的 选择 ， 
也 有 助 于 进行 “ 半 目 动 ” 地 构建 工具 链 。 


2.2.1 GNU 工 具 链 组 成 


编译 过 程 分 为 4 个 阶段 ， 分 别 是 ， 编 译 预 处 理 、 编 译 、 汇 编 以 及 链 
接 。 每 个 阶段 都 涉及 了 若干 工具 ，GNU 将 这 些 工具 分 别 包含 在 3 个 软 


件 包 中 : Binutils、 GCC、Glibc。 


令 Binutils: GNU 将 凡是 与 二 进 制 文件 相关 的 工具 ， 都 包括 在 软件 
包 Binutils 中 。Binutils 就 是 Binary utilities 的 简写 ， 其 中 主要 包括 生成 目 
标 文 件 的 汇编 器 (as) ,链接 目 标 文 件 的 链接 器 (1d) 以 及 若干 处 理 
二 进 制 文件 的 工具 ， 如 objdump、strip 等 。 但 是 也 不 是 Binutils 中 的 所 有 
的 工具 都 是 处 理 二 进 制 文件 的 ， 比 如 处 理 文 本 文件 的 预 编 器 (cpp) 也 
包含 在 其 中 。 


令 GCC: GNU 将 编译 器 包含 在 GCC 中 ， 包 括 C 编 译 器 、C++ 编 译 
器 、Fortran 编 译 器 、Ada 编 译 器 等 。 为 简单 起 见 ， 在 本 章 中 我 们 只 构 


建 COC++ 编 译 器 。GCC 中 还 提供 了 C++ 的 启动 文件 。 


令 Glibc: C 库 包含 在 Glibc 中 。 除 了 C 库 外 ， 动 态 链接 器 (dynamic 
loder/linker) 也 包含 在 这 个 包 中 。 另 外 这 个 包 中 还 提供 C 的 启动 文件 。 
事实 上 ， 有 很 多 C 库 的 实现 ， 比 如 适用 于 Linux 桌 面 系统 的 Glibc、 
EGlibc、uClibc; 在 舱 入 式 系统 上 ， 可 以 使 用 EGlibc 或 者 uClibc， 对 于 
没有 操作 系统 的 系统 ， 就 是 所 说 的 freestanding enviroment, 可 以 选 
择 newlib、dietliibc， 或 者 根本 就 不 用 C 库 。 


除了 这 三 个 软件 包 外 ， 工 具 链 中 还 需要 包括 内 核 头 文件 。 用 户 空 
间 中 的 很 多 操作 和 需要 借助 内 核 来 完成 ， 但 是 通常 用 户 程 序 不 必 直 接 和 
内 核 打 交道 ， 而 是 通过 更 易 用 的 C 库 。C 库 中 的 很 大 一 部 分 函数 是 对 内 
核 服务 的 封装 。 在 某 种 意义 上 ， 内 核 头 文件 可 以 看 作 走 内 核 与 C 库 之 
间 的 协议 。 因 此 ， 构 建 C 库 之 前 ， 需 要 首 移 在 工具 链 中 安 痛 内 核 头 文 
伴 。 


2.2.2 ”构建 工具 链 的 过 程 


针对 我 们 的 具体 情况 ， 目 标 系统 与 箱 主 系统 都 是 基于 IA32 体 系 架 
构 的 ， 所 以 一 种 方式 是 利用 宿主 的 编译 工具 链 来 构建 一 套 独立 于 得主 
系统 的 目 包 含 的 本 地 编译 工具 链 ; 另外 一 种 方式 就 是 构建 一 套 交 叉 编 
译 工具 链 。 在 本 章 中 ， 我 们 采用 交叉 编译 的 方式 构建 工具 链 ， 主 要 原 
因 是 : 


争 Linux 的 主要 应 用 的 场景 之 一 是 供 入 式 领 域 ， 藤 入 式 设备 中 存在 
多 种 不 同 的 体系 以 构 ， 受 限于 藤 入 陈设 备 的 性 能 和 内 存 等 ， 像 编译 链 
接 这 种 工作 都 在 工作 站 或 PC 上 进行 。 因 此 ， 使 用 交叉 编译 的 方法 ， 对 
读 着 进行 甬 入 式 开 发 更 有 共处 。 


多 再 音 ， 采 用 交叉 编译 的 方式 相对 更 有 助 于 读者 理解 链接 过 程 及 
文件 系统 的 组 织 。 所 以 ,虽然 我 们 的 宿主 系统 和 目标 系统 都 古 基 于 
IA32 的 ， 但 是 我 们 利用 交叉 编译 的 方式 构建 编译 工具 链 。 


如 果 读 者 没有 先 入 式 开 发 的 相关 经 验 ， 也 不 必 担 心 ， 交 叉 编 译 与 
本 地 编译 本 质 上 并 无 区 别 。 交 又 编 译 就 是 在 目标 机 器 与 往 主 机 器 体系 
结构 不 同时 使 用 的 编译 方法 。 无 论 是 本 地 编译 还 是 交叉 编 译 ， 工 具 链 
的 各 个 组 件 均 是 运行 在 工作 站 或 者 PC 上 ， 只 不 过 对 于 本 地 编译 ， 我 们 
编译 出 的 程序 运行 在 本 地 系统 上 ， 或 者 至 少 是 运行 在 与 宿主 系统 相同 


的 体系 架构 的 机 器 上 。 而 对 于 交叉 编译 ， 编 译 出 的 程序 是 运行 在 目标 
机 器 上 的 。 


如 图 2-7 所 示 ， 如 果 目 标 机 器 与 宿主 系统 相同 均 为 [A32 涤 构 ， 那 么 
就 使 用 宿主 机 器 上 的 本 地 编译 工具 链 ， 编 译 出 的 二 进 制 代码 对 应 的 也 
是 IA 架 构 的 指令 。 如 果 目 标 机 器 是 其 他 的 体系 结构 的 ， 比 如 ARM， 那 
么 就 需要 使 用 宿主 系统 上 的 交叉 编译 工具 链 ， 编 译 出 的 二 进 制 代码 对 
应 的 也 是 目标 体系 架构 的 指令 ， 如 ARM 指 令 。 
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图 2-7 本 地 编译 和 交叉 编译 


GNU 将 编译 器 和 C 库 分 开放 在 两 个 软件 包 里 ， 好 处 是 比较 灵活 ， 在 
工具 链 中 可 以 选择 不 同 的 C 库 ， 比 如 Glibe、uClibc 等 。 但 是 ， 也 带 来 了 
编译 器 和 C 库 的 循环 依赖 问题 ， 编 译 C 库 需要 C 编 译 器 ， 但 是 C 编 译 器 也 


依赖 C 库 。 虽 然 理论 上 编译 希 不 应 该 依赖 C 库 ，C 编 译 船 只 负 贡 将 源 代 
码 翻译 为 汇编 代码 ， 但 十 事实 并 非 如 此 : 


多 C 编 译 吕 需要 知道 C 库 的 某 些 特性 ， 以 此 来 决定 文 持 哪些 特性 。 
所 以 ， 为 了 文 持 某 些 特性 ，C 编 译 器 依赖 C 库 的 头 文件 。 


C++ 的 库 和 编译 器 需要 C 库 文 持 ， 比 如 异常 处 理 部 分 和 栈 回 调 部 


令 GCC 不 仅 包 含 编 译 事 ， 还 包含 一 些 库 ， 这 些 库 通 弟 依 赖 C 库 。 


令 C 编 译 占 本 冉 也 会 使 用 C 库 的 一 些 范 数 。 


但 是 ， 邓 运 的 是 ，C99 标 准 定义 了 两 种 运行 环境 ， 一 种 是 "hosted 
environment"， 针 对 的 是 具有 操作 系统 的 环境 ， 程 序 一 般 是 运行 在 操作 
系统 之 上 的 ， 因 此 这 个 操作 系统 不 仅 是 内 核 ， 还 包括 外 围 的 C 库 ， 对 于 
程序 来 说 ， 就 是 一 个 "hosted environment"。 另 外 一 种 是 "freestanding 
environment"， 就 是 程序 不 需要 额外 环境 的 文 持 ， 直 接 运 行 在 裸 机 

(bare metal) 上 ， 比 如 Linux 内 核 ， 以 及 一 些 运行 在 没有 操作 系统 的 裸 
板 上 的 程序 ， 不 再 依赖 操作 系统 内 核 和 C 库 ， 所 有 的 功能 都 在 单个 程序 
的 内 部 实现 。 


针对 这 两 种 运行 环境 ，C99 标 准 分 别 定 义 了 两 种 实现 : 一 种 称 
为 "hosted implementation"， 文 持 完 整 的 C 标 准 ， 包 括 语 言 标 准 以 及 库 标 


准 ， 男 外 一 种 是 "freestanding implementation"， 这 种 实现 方式 支持 完整 
的 语言 标准 ， 但 是 只 要 求 文 持 部 分 库 标 准 。C99 标 准 要 求 "hosted 
implementation" 文 持 "freestanding implementation"， 通 常 是 通过 回 编 译 


器 传递 参数 来 控制 编译 器 采用 哪 种 方式 进行 编译 。 


通常 "hosted implementation" 的 实现 包含 编译 器 (比如 GCC) 和 C 库 

(比如 Glibc) 。 而 "freestanding implementation" 的 实现 通常 只 包含 编译 

全 ， 如 GCC， 最 多 再 加 上 一 个 简单 的 库 ， 比 如 典型 的 newlib。 但 是 如 果 
没有 newlib 的 支持 ，GCC 自 己 也 可 以 自给 自足 。 


"freestanding implementation" 的 实现 ， 恰 恰 解 决 了 我 们 提 到 的 GCC 
和 Glibc 的 循环 依赖 问题 。 我 们 可 以 先 编译 一 个 仅 文 持 "freestanding 
implementation" 的 GCC， 因 为 在 这 种 情况 下 ， 不 需要 C 库 的 文 持 。 但 
是 "freestanding implementation" 的 GCC 却 可 以 编译 Glibc， 因 为 Glibc 也 是 
一 个 目 包含 的 ， 完 全 自给 自足 。 事 实 上 ，Glibc 中 也 有 小 部 分 地 方 使 用 
了 GCC 的 代码 ， 但 是 这 不 会 带 来 依赖 的 麻烦 ， 因 为 GCC 一 定 是 在 Glibc 
之 前 编译 的 。 


在 编译 目标 系统 的 C 库 ， 甚 至 是 编译 GCC 中 包含 的 目标 系统 上 的 库 
时 ， 都 需要 链接 器 ， 因 此 ，Binutils 是 编译 器 和 C 库 共同 依赖 的 。 索 性 
Binutils 几 乎 没有 任何 依赖 ， 只 需要 利用 宿主 系统 的 工具 链 构建 一 套 交 
又 Binutils 即 可 。 


另外 值得 一 提 的 是 内 核 头 文件 。 在 Linux 系 统 上 ， 在 编译 C 库 前 需 
要 安装 目标 系统 的 内 核 头 文件 ， 从 某 种 意义 上 讲 ， 内 核 头 文件 就 是 C 库 
和 内 核 之 间 的 一 个 协议 (Protocol) 。 而且 ，C 库 会 根据 内 核 头 文件 检 
查 内 核 提 供 了 哪些 特性 ， 以 及 需要 在 C 库 层面 模拟 哪些 内 核 没有 提供 的 


服务 。 


综 上 所 述 ， 我 们 可 以 按照 如 下 步骤 构建 工具 链 : 

1) 构建 交叉 Binutils， 包 括 汇编 器 as、 链 接 器 ld 等。 

2) 构建 临时 的 交叉 编译 器 〈 仅 支持 freestanding) 。 

3) 安装 目标 系统 的 内 核 头 文件 。 

4) 构建 目标 系统 的 C 库 。 

5) 构建 完整 的 交叉 编译 器 (支持 hosted 和 freestanding) 。 


最 后 提醒 读者 注意 一 点 ， 上 面 的 目标 平台 也 是 IA32 的 ， 并 且 使 用 
的 C 库 是 Glibc。 如 条 是 其 他 平台 的 ， 或 者 是 用 了 不 同 的 C 库 ， 编 译 过 程 
可 能 会 略 有 差异 ， 比 如 为 了 使 最 终 编 译 C 库 的 编译 器 具有 更 多 的 特性 ， 
有 的 编译 过 程 将 使 用 freestanding 编 译 强 编译 一 个 简化 版 的 hosted 编 译 
器 ， 然 后 用 这 个 hosted 的 GCC 再 编译 Glibc 等 。 但 是 ， 无 论 如 何 ， 交 又 
编译 的 关键 还 是 构建 freestanding 的 编译 器 。freestanding 的 编译 器 解决 了 


鸡 和 和 蛋 的 问题 〈 即 GCC 和 Glibc 的 循环 依赖 ) ， 一 旦 解决 了 鸡 和 有 蛋 的 问 
题 后 ， 其 他 的 问题 融 都 迎刃而解 。 


2.2.3 ”准备 工作 


1. 痢 建 普 通用 户 vita 


为 了 避免 误 操 作 给 答 主 系统 带 来 灾难 性 的 后 果 ， 在 编译 过 程 中 我 们 使 
普通 用 户 ， 避 人 免 不 小 心 使 用 新 编译 的 某 些 库 履 盖 答 主 系 统 的 库 。 我 们 新 
建 一 个 普通 用 户 vita: 


root@baisheng:~# groupadd vita 
root@baisheng:~# useradd -m -s /bin/bash -g vita vita 


我 们 还 要 新 建 一 个 组 vita， 用 户 vita 属 于 这 个 组 。 参 数 "-m" 表 示 创 建 vita 
用 户 的 属 主 目录 ， 默 认 是 /home/vita; "-s/bin/bash" 表 示 使 用 bash shell; "-g 


vita" 表 示 将 vita 加 入 组 vita 。 


在 某 些 情况 下 ， 我 们 可 能 需要 使 用 vita 执 行 一 些 超级 用 户 才 有 权限 执行 
的 命令 ， 因 此 ， 我 们 让 vita 成 为 sudoers， 在 /etc/sudoers.d 目 录 下 添加 一 个 文 
件 vita， 其 内 容 如 下 : 


Vita ALL= (ALL) NOPASSWD: ALL 


2. 建 并 工作 目录 


为 了 便于 管理 ， 我 们 需要 建立 一 个 工作 目录 ， 这 个 目录 可 以 建立 在 任 
一 目录 下 。 笔 者 使 用 了 一 个 单独 的 分 区 ， 并 且 挂 载 在 /vita 目 录 下 。 在 该 目录 
下 ， 建 立 相 应 的 工作 目录 的 方法 如 下 : 


root@baisheng:/vita# mkdir source build cross-tool \ 
cross-gcc-tmp sysroot 
root@baisheng:/vita# chown -R vita.vita /vita 


其 中 ，source 目 录 中 存放 的 是 源 代码 ，build 目 录用 作 编 译 ;， cross-tools 
目录 保存 交叉 编译 工具 。 因 为 在 整个 编译 过 程 中 ， 编 译 需 将 被 编译 两 次 ， 
CR 避免 这 个 临时 的 
freestanding 编 译 器 污染 最 后 的 工具 链 。 编 译 好 的 目标 机 器 上 的 文件 安装 在 
sysroot 目 录 下 ，sysroot 目 录 相 当 于 目标 系统 的 根 文件 系 统 。 另 外 ， 我 们 使 用 
chown 更 改 这 些 目 录 的 属 主 和 属 组 ， 使 vita 用 户 有 权限 使 用 这 些 目 录 及 目录 
下 的 文件 。 


3. 定 义 环境 变量 


为 了 简化 编译 过 程 中 的 一 些 命令 ， 我 们 需要 定义 一 些 环境 变量 。 同 时 
为 了 避免 每 次 切换 到 vita 用 户 时 ， 都 需要 手动 重新 定义 ， 我 们 将 其 定义 
在 /home/vita/.bashrc 中 。 


unset LANG 

export HOST=i686-pc-linux-gnu 
export BUILD=$HOST 

export TARGET=i686-none-linux-gnu 
export CROSS TOOL=/vita/cross-tool 


export CROSS GCC TMP=/vita/cross-gcc-tmp 
export SYSROOT=/vita/sysroot 
PATH=$CROSS TOOL/bin:$CROSS GCC TMP/bin:/sbin:/usr/sbin:$PATH 


如 采 使 用 的 是 中 文 环 境 的 操作 系统 ， 那 么 为 了 避免 不 必要 的 麻烦 ， 要 
在 环境 中 将 其 设置 英文 环境 ， 即 上 面 的 unset LANG， 因 为 ， 在 中 文 环境 
下 ， 有 些 工具 ， 比 如 readelf， 在 输出 ELF 文 件 的 信息 时 ， 多 此 一 举 地 将 很 多 
英文 翻译 为 了 中 文 ， 可 能 给 有 些 脚本 处 理工 具 市 来 一 些 麻烦 。 


为 了 使 后 面 的 构建 过 程 可 以 找到 的 交 义 编译 工具 ， 我 们 将 安装 交叉 编 
译 工具 的 目 孙 添加 到 环境 变量 PATH 中 ， 包 括 临时 的 GCC 存储 的 目 永 。 广 意 
一 点 ， 临 时 的 GCC 存储 的 目 孙 一 定 要 在 最 终 正 式 的 工具 链 目 永 的 后 面 ， 确 
保安 装 最 终 的 交叉 编译 器 后 ， 在 编译 时 将 优先 使 用 最 终 的 交叉 编译 器 。 


Binutils、GCC 以 及 Glibc 的 配置 脚本 中 均 包含 三 个 配置 参数 : HOST 、 
BUILD 和 TARGET， 这 三 个 配置 参数 的 值 均 是 大 致 形 如 ARCH-VENDOR-OS 
三 元 组 的 组 合 。 在 编译 前 ， 可 以 通过 配置 选项 设 定 这 几 个 参数 的 值 。 如 果 
配置 时 不 显示 指定 这 几 个 参数 ， 编 译 脚 本 将 自动 探测 编译 所 在 的 机 器 的 相 
关 值 。 


读者 可 以 通过 查看 变量 MACHTYPE， 或 者 查看 编译 时 配置 过 程 的 结 
果 ， 确 定 机 器 的 三 元 组 。 以 笔者 的 机 恬 为 例 ， 该 值 为 686-pc-linux-gnu， 表 
示 机 如 的 CPU 型 号 为 686，vendor 为 none， 操 作 系 统 为 linux-gnu 。 


root@baisheng:~# echo $MACHTYPE 
i1686-pc-linux-gnu 


如 果 HOST 的 值 和 TARGET 的 值 相同 ， 那 么 编译 脚本 就 构建 本 地 编译 工 
具 。 只 有 当 HOST 和 TARGET 的 值 不 同时 ， 编 译 脚 本 才 构 建交 叉 编译 工具 。 


因此 ， 虽 然 目标 平台 也 是 x86 架 构 的 ， 但 是 为 了 使 用 交叉 编译 的 方式 ， 我 们 
在 配置 时 故意 显示 设置 TARGET 参 数 为 i686-none-linux-gnu， 如 此 ， 
TARGET 就 会 与 编译 脚本 自行 检测 到 的 HOST (对 于 笔者 的 机 器 来 说 ， 即 
i686-pc-linux-gnu) 不 同 ， 从 而 构建 交叉 编译 工具 。 读 者 可 根据 目 己 的 具体 
环境 进行 调整 ， 总 之 ， 要 使 TARGET 与 HOST 不 同 。 为 了 方便 在 编译 时 设置 
配置 参数 ， 因 此 我 们 定义 了 环境 变量 BUILD、HOST 和 TARGET 。 


4. 切 换 到 vita 用 户 
准备 工作 完成 后 ， 我 们 使 用 如 下 命令 切换 到 vita 用 户 : 
root@baisheng:~# su - vita 


注意 ， 这 里 我 们 切换 到 vita 用 户 使 用 的 是 "su-" 而 不 是 "su"。 后 者 只 是 切 


/DA 


换 了 身份 ，shell 的 环境 仍然 是 原 用 户 的 shell 环 境 ， 而 前 者 将 shell 环 境 也 切换 
到 了 vita。 


2.2.4 构建 二 进 制 工具 


Binutils 包 含 各 种 用 来 操作 二 进 制 目标 文件 的 工具 ， 其 中 包括 GNU 汇 纺 
器 as 和 链接 器 14， 处 理 静 态 库 的 工具 ar 和 ranlib ， 系 统 程序 员 常 用 的 


objdump 、readelf、nm 、strings、stip 等 。 


Binutils 推 荐 使 用 单独 的 目录 进行 编译 : 


vita@baisheng:/vita/builds tar xvf \ 
SOUEcCe/Dinutils=2.23;1, tars bz2 
vita@baisheng:/vita/builds mkdir binutils-build 
vita@baisheng:/vita/builds$ cd binutils-build 
vita@baisheng:/vita/build/binutils-builds 
sainutils-2.23,1/60nfigure: \ 
--prefix=$CROSS TOOL --target=$TARGET \ 
--wWwith-sysroot=$SYSROOT 


下 面 介绍 各 个 配置 参数 的 意义 。 


已 过 必 7 


令 --prefix=$CROSS_TOOL: 通过 参数 --prefix 指 定安 装 脚 本 将 编译 好 的 
二 进 制 工 具 安 装 到 保存 交叉 编译 工具 链 的 $CROSS_TOOL 目 录 下 。 


令 --target=$TARGET: 因为 没有 显示 指定 参数 --host 和 --build， 所 以 编 
译 脚本 将 自动 探测 HOST 和 BUILD 的 值 。 对 于 笔者 的 机 器 来 说 ， 探 测 到 的 
HOST 和 BUILD 值 相同 ， 都 为 686-pc-linux-gnu。 在 前 面 设置 环境 变量 时 ， 
我 们 故意 将 环境 变量 TARGET 的 值 设置 1686-none-linux-gnu， 与 HOST 自 动 探 
测 的 值 不 同 ， 因 此 ， 编 译 脚本 据 此 判断 这 是 在 构建 交叉 编译 工具 链 ， 继 而 


| 


Se 


年 指导 宿主 系统 的 工具 链 编译 “运行 在 本 机 ， 但 是 最 后 编译 链接 的 程序 / 库 是 
运行 在 $TARGET 上 ”的 交叉 二 进 制 工具 。 


@ --with-sysroot=$SYSROOT: 我 们 通过 参数 --with-sysroot 告 诉 链接 
需 ， 目 标 系统 的 根 文 件 系统 放置 在 $SYSROOT 目 孙 下 ， 链 接 时 到 
$SYSROOT 目 录 下 寻找 相关 的 库 。 


配置 完成 后 ， 使 用 如 下 命令 编译 并 安 凑 : 


vita@baisheng:/vita/build/binutils-builds$ make 
vita@baisheng:/vita/build/binutils-builds$s make install 


Binutils 将 二 进 制 工具 安装 在 $CROSS_TOOL/bin 目 录 下 ， 这 里 不 浪费 篇 
幅 一 一 列举 各 个 工具 的 具体 功能 了 ， 读 者 可 以 使 用 man 进 行 查看 。 


除了 安装 二 进 制 工具 外 ，Binutils 还 安装 了 链接 脚本 ， 安 装 目录 是 : 


$CROSS TOOL/i686-none-linux-gnu/lib/ldscripts 


其 中 elf_i386.x 用 于 IA32 上 ELF 文 件 的 链接 ，elf_i386.xbn、elf_i386.xc 等 
分 别 对 应 ld 使 用 不 同 的 链接 参数 时 使 用 的 链接 脚本 ， 如 果 使 用 了 "-N" 参 数 ， 
那么 ld 使 用 链接 脚本 elf_i386.xbn 。 


Binutils 在 $CROSS_TOOL/i686-none-linux-gnu/bin 目 录 下 也 安装 了 一 些 
二 进 制 工 具 ， 这 些 是 编译 右 内 部 使 用 的 ， 我 们 不 必 关 心 ， 其 实 这 个 目录 下 
的 工具 与 $CROSS_TOOL/bin 目 录 下 的 工具 完全 相同 ， 只 是 名 称 不 同 而 已 。 


2.2.5 ”编译 freestanding 的 交叉 编译 融 


正如 我 们 前 面 讨论 的 ， 因 为 编译 器 和 C 库 之 间 循 环 依赖 的 问题 ， 我 们 需 
要 找到 一 个 办 法 解决 这 个 鸡 和 和 蛋 的 问题 。 幸 运 的 是 ，C 编 译 需 提供 了 一 个 
freestanding 的 实现 ， 即 一 个 不 依赖 C 库 的 编译 右 。 那 么 如 何 编译 一 个 


freestanding 的 编译 絮 昵 ? 


GCC 提 供 了 一 个 编译 选项 --with-newlib。 这 是 一 个 让 人 困惑 的 C 库 参 
数 ， 因 为 newlib 本 身 就 是 一 套 C 库 的 实现 ， 所 以 容易 让 人 误解 为 工具 链 中 使 
用 的 C 库 是 newlib， 而 不 是 其 他 的 C 库 。 事 实 上 ， 在 构建 交叉 编译 融 时 ， 其 
有 着 特殊 的 意义 ， 文 件 configure.ac 中 的 注释 解释 得 很 清楚 。 


gcc-4.7.2/gcc/configure.ac 


# If this is a cross-compiler that does not 
# have its own set of headers then define 


+# Tnhibit Tibe 
# If this is using newlib, without having the headers available now, 
# then define inhibit libc in LIBGCC2 CFLAGS. 
# This prevents libgcc2 from containing any code which requires libc 
# support. 
: ${inhibit libc=false} 
if { { test x$host != x$target && test "x$with sysroot" =x ; } | 
test x$with newlib = xyes ; } && 

{ test "x$with headers" = x || test "x$with headers" = xno ; }; 

then 


inhibit libc=true 


注释 中 说 明 ， 在 构建 交叉 编译 器 且 尚 未 安装 C 库 头 文件 的 情况 下 ， 需 要 
定义 变量 inhibit_libc。 一 旦 定义 了 该 变量 ， 将 去 掉 libgcc 库 中 对 C 库 的 一 切 依 
赖 ， 转 而 使 用 GCC 内 部 的 实现 。 如 下 面 的 代码 片段 : 


UGC-A4s 7 2/ Tibgco/ortatutt.s 


#if defined (OBJECT FORMAT ELF) \ 
&& !defined (OBJECT FORMAT FLAT) \ 
&& defined (HAVE LD EH FRAME HDR) \\ 
&& ldefined(inhibit libc) && !defined (CRTSTUFFT O) \ 
&& defined( FreeBSsD ) && FreeBsD >= 7 
#include <link.h> 
# define USE PT GNU EH FRAME 
#endif 


我 们 看 到 ， 如 果 没 有 定义 inhibit_libc， 则 libgcc 库 中 可 能 会 包含 link.h， 
而 这 恰恰 是 glibc 提 供 的 头 文件 。 


换 名 话说， 我 们 可 以 通过 将 变量 inhibit_libc 赋 值 为 tue， 告 诉 GCC 编 译 
为 freestanding 实 现 。 但 是 ， 遗 憾 的 是 ，GCC 并 没有 暴露 一 个 直观 的 配置 选 
项 供 配置 时 设置 这 个 变量 ， 相 反 需 要 通过 另外 相关 的 变量 来 控制 变量 
inhibit_libc 的 值 。 


再 次 回顾 文件 gcc-4.7.2/gcc/configure.ac 中 的 关于 定义 inhibit_libc 的 条 件 
语句 部 分 ，f 中 的 条 件 如 下 : 


1) 如 果 是 交叉 编译 且 未 设置 --with-sysroot， 或 者 设置 了 --with-newlib。 
2) 没有 设置 --with-headers。 


对 于 条 件 1) ， 因 为 我 们 使 用 了 sysroot 的 方式 ， 所 以 要 满足 第 一 个 条 
件 ， 就 需要 设置 --with-newlib。 对 于 条 件 2) ， 因 为 我 们 没有 指定 头 文件 ， 
所 以 目 然 成 立 。 


看 了 前 面 的 讨论 ， 相 信 读 者 就 比较 清楚 --with-newlib 的 意义 了 ， 使 用 -- 
with-newlib 并 不 是 强行 指定 GCC 使 用 newlib 实 现 的 C 库 。 我 们 无 从 考究 参数 - 
-with-newlib 的 出 处 ， 但 是 因为 newlib 的 初 囊 就 是 作为 freestanding 环 境 中 的 C 
库 ， 或 许 这 个 参数 的 名 称 来 源 于 此 。 


下 面 ， 我 们 开始 编译 用 于 freestanding 环 境 的 gcc 编 译 絮 ， 首 和 完 解 开 源码 
包 : 


vita@baisheng:/vita/builds tar xvf ../source/gcc-4.7.2.tar.bz2 


GCC 依 赖 包 括 浮 点 计算 、 复 数 计算 的 几 个 数学 库 GMP、MPFR 和 
MPC。 可 以 先 单独 编译 这 些 库 ， 然 后 通过 GCC 的 配置 选项 如 --with-mpc、-- 
with-mp 人 fr、--with-gmp 告 知 GCC 这 几 个 库 的 位 置 。 也 可 以 将 这 几 个 库 的 源码 
解压 到 GCC 的 源码 目录 下 ， 在 编译 时 ，GCC 会 自动 探测 并 编译 。 这 里 我 们 
采用 后 者 ; 


vita@baisheng:/vita/build/gcc-4.7.2$ tar xvf \ 

sri/Bource/qmp=S0a0v5 tarsbz2 
vita@baisheng:/vita/build/gcc-4.7.2$ mv gmp-5.0.5/ gmp 
vita@baisheng:/vita/build/gcc-4.7.2$ tar xvf \ 

ta oc OUEGe/ MDE LL Bz2 
vita@baisheng:/vita/build/gcc-4.7.2$ mv mpfr-3.1.1/ mpfr 
vita@baisheng:/vita/build/gcc-4.7.2$ tar xvf \ 

Oreme- TO0ulo tardT 
vita@baisheng:/vita/build/gcc-4.7.2$ mv mpc-1.0.1/ mpc 


GCC 要 求 在 单独 的 目录 编译 ， 因 此 我 们 创建 编译 目录 gcc-build， 配 置 如 
下 : 


Vitae@baisheng:/vita/builds mkdir gcc-build 
vita@baisheng:/vita/builds cd gcc-build 
vita@baisheng:/vita/build/gcc-builds$ ../gcc-4.7.2/configure \ 
--prefix=$CROSS GCC TMP --target=$TARGET \ 
--with-sysroot=$SYSROOT \ 
--with-newlib --enable-languages=c \ 
--with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src \ 
--with-mpfr-lib=/vita/build/gcc-build/mpfr/src/.libs \ 
--disable-shared --disable-threads \ 
--disable-decimal-float --disable-libquadmath \ 
--disable-libmudflap --disable-libgomp \ 
--disable-nls --disable-libssp 


下 面 介绍 各 个 配置 参数 的 意义 


@ --prefix=$CROSS_GCC_TMP: freestanding 的 GCC 与 最 终 的 hosted 的 
GCC 还 是 有 些 差别 的 ， 这 里 的 freestanding 的 GCC 只 是 一 个 临时 的 GCC， 并 

会 用 作 最 终 的 交叉 编译 器 。 所 以 ， 为 了 避免 污染 最 后 的 工具 链 ， 这 里 将 
freestanding 的 GCC 安 装 在 一 个 临时 的 目录 $CROSS_GCC_TMP 中 。 


@ --target=$TARGET: de 告 
诉 编译 脚本 构建 的 预 处 理 器 、 编 译 器 等 是 运行 在 本 机 上 的 ， 但 是 最 后 编译 
的 程序 或 库 是 运行 在 目标 体系 结构 $STARGET 上 的 ， 即 构建 交叉 编译 器 。 


全 --with-sysroot=$SYSROOT: 配置 参数 --with-sysroot 告 诉 GCC 目标 系 
统 的 根 文 件 系 统 存 放 在 $SSYSROOT 目 录 下 ， 编 译 时 到 $SYSROOT 目 录 下 查 
找 目 标 系统 的 头 文件 以 及 库 。 


全 --enable-languages=c: 编译 C 库 只 需要 C 编 译 器 ， 所 以 这 个 临时 的 
freestanding 编 译 俐 只 文 持 C 编 译作 。 而 且 像 C++ 编 译 器 ， 即 使 想 编译 也 是 有 
心 无 力 ， 因 为 其 依赖 目标 系统 的 C 库 ， 所 以 目前 也 没有 条 件 进 行 编译 。 


令 --disable-shared: 除了 编译 器 外 ， 软 件 包 GCC 中 也 包含 有 一 个 运行 时 
库 libgcc。 该 库 主 要 包括 一 些 目 标 处 理 器 不 支持 的 数学 运算 、 异 常 处 理 ， 以 
及 一 些小 的 比较 复杂 的 便利 函数 。 在 默认 情况 下 ， 会 既 编 译 libgcc 的 静态 库 
版 本 ， 也 编译 动态 库 版 本 。 但 是 动态 库 与 静态 库 不 同 ， 加 载 器 在 加 载 动态 
库 后 需要 进行 一 些 初始 化 ， 比 如 初始 化 变量 ， 而 这 些 相关 的 代码 是 在 C 库 的 
启动 文件 中 实现 的 ， 包 括 crt1.0、crti.o 等 ， 因 此 ， 编 译 libgce 的 动态 版 本 时 将 
会 链接 启动 文件 。 但 是 此 时 目标 机 器 的 C 库 尚未 编译 ， 链 接 将 发 生 类 似 “ 找 
不 到 crt1.o 文 件 ” 的 错误 。 因 此 ， 这 里 通过 配置 选项 --disable-shared 告 诉 编译 
脚本 不 要 编译 libgcc 的 动态 库 ， 仅 编译 静态 库 。 


全 --with-mpfr-include 和 --with-mpfr-lib: 对 于 MPFR 这 个 库 ， 其 目录 结构 
与 GCC 的 默认 设 定 有 一 些 差异 ， 因 此 我 们 需要 明确 指定 ， 否 则 编译 时 会 报 
找 不 到 libmpfr 的 钳 误 。 这 残 是 配置 时 指定 配置 选项 --with-mpfr-include 和 -- 
with-mpfr-lib 的 原因 。 


另外 我 们 还 通过 形 如 --disable-xxx 这 样 的 参数 禁止 了 一 些 库 的 编译 ， 也 
天 财 了 编译 器 的 一 些 特 性 ， 因 为 目前 这 个 freestanding 的 交叉 编译 右 根 本 不 
需要 这 些 特性 ， 我 们 只 需要 一 个 基本 的 能 够 将 C 库 中 的 代码 翻译 为 目标 机 器 
的 指令 这 样 一 个 基本 的 编译 侣 即 可 。 而 且 ， 最 重要 的 是 ， 某 些 库 和 特性 中 
可 能 会 依赖 C 库 ， 因 此 ， 临 时 的 freestanding 编 译 器 不 文 持 不 必要 的 特性 ， 也 
不 编译 不 必要 的 库 。 


编译 完成 后 ， 使 用 如 下 命令 进行 安 效 : 


vita@baisheng:/vita/build/gcc-builds make 
vita@baisheng:/vita/build/gcc-builds make install 


在 使 用 --disable-shared 禁 止 编译 libgcc 的 动态 库 后 ，GCC 的 编译 脚本 将 
不 再 编译 库 ]ibgcc_eh.a。 但 是 后 面 编译 Glibc 时 ，Glibc 将 链接 ]ibgcc_eh.a， 
Glibc 的 Thread cancellation 使 用 了 GCC 中 的 异常 处 理 部 分 的 实现 ， 这 里 eh 就 
是 exception handling 的 缩写 。 我 们 可 以 直接 修改 Glibc 中 的 Makeconfig 文 件 ， 
或 者 通过 建 一 个 指 辐 libgcc.a 的 符号 链接 libgcc_eh.a 来 解决 这 个 问题 。 因 为 
libgcc.a 中 包含 libgcc_eh.a 所 包含 的 全 部 内 容 。 我 们 采用 后 者 来 解决 这 个 问 


题 。 


vita@baisheng:/vita/cross-gcc-tmps$ ln -s libgcc.a \ 
lib/gcc/i686-none-linux-gnu/4.7.2/libgcc eh.a 


2.2.6” 安 狭 内 核 头 文件 


应 用 程序 很 少 直接 通过 内 核 提 供 的 接口 使 用 内 核 提供 的 服务 ， 而 通常 
都 是 用 C 库 使 用 内 核 提供 的 服务 。C 库 的 主要 内 容 之 一 是 对 内 核 服 务 的 封 
装 。 以 系统 调用 _exit 为 例 : 


glibc-2.15/sysdeps/unix/sysv/linux/i386/ exit.Ss: 
_exit: 
movl 4(%esp), %Sebx 


/* Try the new syscall first. */ 
#ifdef NR exit group 


movl $__ NR exit group, %eax 
ENTER KERNEL 
#endif 


/* Not available. Now the old one. */ 

movl $_ NR exit, %eax 

/* Don't bother using ENTER KERNEL here. If the exit group 
syscall is not available AT SYSINFO isn't either. */ 

int $0x80 


Glibc 中 使 用 的 系统 调用 号 _ NR_exit_group 和 ”NR_exit 都 是 在 内 核 中 定 
义 的 。 因 此 ， 在 编译 目标 系统 的 C 库 之 前 ， 我 们 首先 需要 安装 内 核 头 文件 。 


首先 解压 内 核 源码 ， 并 清理 内 核 。 


vita@baisheng:/vita/builds$ tar xvf ../source/linux-3.7.4.tar.xz 
vita@baisheng:/vita/build/linux-3.7.4$ make mrproper 


我 们 可 以 通过 变量 ARCH 指 出 目标 系统 的 染 构 ， 在 默认 情况 下 ，make 
将 目 动 探测 宿主 系统 的 架构 ， 并 认为 目标 系统 的 架构 与 答 主 系统 的 架构 相 


同 。 对 于 IA32 来 说 ， 其 ARCH 值 是 i386。 另 外 ， 在 安装 前 ， 还 需要 对 内 核 头 
文件 进行 一 些 合法 化 检查 。 
vita@baisheng:/vita/build/linux-3.7.4$ make ARCH=i386 \\ 
headers _ check 


vita@baisheng:/vita/build/linux-3.7.4$ make ARCH=i386 \\ 
INSTALL HDR PATH= $SYSROOT/us r/headers instal 1 


完成 安装 后 ， 我 们 可 以 看 到 的 内 核定 义 的 系统 调用 号 在 文件 unistd_32.h 
中 。Glibc 就 可 以 包含 该 头 文件 ， 并 使 用 诸如 _NR_exit 等 安定 义 。 


/vita/sysroot/usr/include/asm/unistd 32.h : 


#define NR restart syscall 0 
#define NR exit 1 
#define NR fork 2 
#define NR read 3 


#define NR exit group 252 


2.2.7 ”编译 目标 系统 的 C 库 


作为 Linux 操 作 系 统 中 最 底层 的 API， 几 乎 运行 于 Linux 操 作 系 统 上 的 任 
何 程序 都 会 依赖 于 C 库 。Glibc 除 了 封装 Linux 内 核 所 提供 的 系统 服务 外 ， 也 
提供 了 C 标 准 规定 的 必要 功能 的 实现 ， 如 字符 串 处 理 、 数 学 计算 等 。 


在 Ubuntu12.10 中 ， 系 统 默认 安装 的 awk 是 mawk， 我 们 需要 男 外 安装 
gawk， 因 为 mawk 与 Glibc 中 使 用 的 awk 脚本 在 兼容 上 有 一 些 问题 。 


root@baisheng:~# apt-get install gawk 


解压 源码 ， 并 打开 修复 编译 错误 的 patch 。 


vita@baisheng:/vita/builds tar xvf ../source/glibc-2.15.tar.xz 
vita@baisheng:/vita/builds cd glibc-2.15 
vita@baisheng:/vita/build/glibc-2.15$ patch -pl \ 

& vail suourece/glibe=2, 155CpUuiqd pateh 
vita@baisheng:/vita/build/glibc-2.15$ patch -pl \ 

< sf a /SOource/glibc=2..15=-8 frexp.patch 


Glibc 要 求 在 单独 的 目录 编译 ， 我 们 新 建 目录 glibc-build 用 来 编译 Glibc 。 


vita@baisheng:/vita/builds$s mkdir glibc-build 
vita@baisheng:/vita/builds$ cd glibc-build 
vita@baisheng:/vita/build/glibc-builds ../glibc-2.15/configure \ 
--prefix=/usr --host=$TARGET \ 
--enable-kernel=3.7.4 --enable-add-ons \ 
--with-headers=$SYSROOT/usr/include \ 
libc cv forced unwind=yes libc cv c¢ cleanup=yes \ 
libc cv ctors header=yes 


下 面 介绍 各 个 配置 参数 的 意义 


@ --host=$TARGET: 注意 这 里 与 Binutils 和 GCC 编译 时 指定 的 是 target 参 
数 不 同 ，Glibc 指 定 的 是 host 参 数 ， 但 这 里 host 的 值 是 STARGET， 也 就 是 说 C 
库 运 行 所 在 的 host 是 $TARGET。 换 句 话说 ， 就 是 告诉 刚刚 编译 的 交叉 编译 
器 、 汇 编 器 、 链 接 器 等 编译 一 个 运行 在 STARGET 平 台 的 C 库 。 


人 --enable-kernel=3.7.4: 除非 是 制作 发 行 版 ， 需 要 一 个 兼容 更 早 内 核 的 
C 库 ， 否 则 我 们 没有 必要 疝 后 兼容 较 早 版 本 的 内 核 ， 因 为 这 样 只 会 降低 C 库 
的 效率 ， 包 括 增加 C 库 的 体积 ， 甚 至 影响 运行 速度 。 本 书 构建 的 系统 使 用 的 
内 核 版 本 为 3.7.4， 因 此 ，C 库 只 支持 3.7.4 及 以 后 版 本 的 内 核 就 可 以 了 。 当 
然 ， 如 采 这 个 C 库 运行 在 早 于 3.7.4 版 本 的 内 核 上 ， 将 报 类 似 于 "FATAL:kernel 


too old" 的 致命 错误 ， 拒 绝 运行 。 


令 --enable-add-ons: 编译 C 库 源码 目录 下 全 部 的 add-on， 如 libidn、 


nptl。 


多 --with-headers=$SYSROOT/usr/include: 告诉 编译 脚本 内 核 头 文件 所 
在 的 目录 。 


@ libc_cv_forced_unwind=yes 和 llibc_cv_c_cleanup=yes: Glibc 中 的 NPTL 
将 检测 C 编 译 器 对 线程 的 支持 ， 而 freestanding 的 GCC 是 不 支持 线程 的 ， 
此 ， 我 们 这 里 欺骗 一 下 Glibc 中 的 NPTL， 告 诉 它 编译 器 是 支持 线程 的 ， 采 用 
的 方法 是 设置 这 样 两 个 参数 。 


令 libc_cv_ctors_header=yes: 临时 的 freestanding 的 C 编 译 旭 不 支持 启动 
代码 与 构造 男 数 文 持 ， 因 此 ， 这 里 我 们 再 次 其 狂 一 下 Glibc， 人 为 地 告诉 


Glibc 编 译 套 是 文 持 局 动 代码 的 ， 也 是 文 持 构造 画 数 的 。 


配置 完成 后 ， 进 行 编译 安装 。 我 们 通过 指定 参数 install_root 为 
$SYSROOT， 将 C 库 安装 到 $SYSROOT， 即 /vita/sysroot 目 录 下 。 
vita@baisheng:/mnt/vita/build/glibc-builds make 


vita@baisheng:/mnt/vita/build/glibc-builds make \ 
install root=$SYSROOT install 


下 面 介绍 一 下 Glibc 安 装 的 主要 文件 。 


(1) C 库 


Glibc 除 了 将 最 基本 、 最 第 用 的 函数 封闭 在 libc 中 外 ， 叉 将 功能 相近 的 一 
些 函 数 封 于 到 一 些 子 库 里 ， 比 如 将 线程 相关 函数 封装 在 libpthread 中 ， 将 与 
加 密 算 法 相关 的 函数 封闭 在 libcrypt 中 ， 等 等 。 


Glibc 除 了 安 狠 库 文件 本 映 外 ， 还 建立 了 符号 链接 ， 包 括 : 


多 动态 链接 时 使 用 的 共 至 库 符 号 链接 。 其 命名 格式 一 般 为 : 
libLIBRARY_NAME.so.MAJOR_REVISION_VERSION 。 


多 开发 时 使 用 的 共享 库 的 符号 链接 。 其 命名 格式 一 般 为 : 
libLIBRARY_NAME.so。 


比如 数学 库 的 共享 库 及 其 符号 链接 如 下 : 


vita@baisheng:/vita/sysroot/libs$ ls -1 libm* 
-rwxr-xr-x 1 vita vita 792815 Jan 23 10:29 libm-2.15.so 


lrwxrwxrwx 1 vita vita 12 HJan B23 T0529 Tibm de =%, Tibi 2 T5330 
-rwxr-xr-x 1 vita vita 42195 Jan 23 10:29 libmemusage.so 
LEWXLWELWE, TL ViEd Vita 7 Jan 29 L777 11bDMOUNGCBouL = 


libmount .so.1.1.0 
二 LE T46759 Jan 29 T7717 LDnount EC 


其 中 ，libm-2.15.so 是 数学 库 的 共享 库 本 身 ，libm.so.6 是 运行 时 使 用 的 符 
号 链接 ，libm.so 是 编译 链接 时 使 用 的 符号 链接 。Glibc 将 运行 时 使 用 的 库 安 
装 在 SSYSROOT/ib 目 录 下 ， 其 中 包括 共享 库 文件 本 身 及 动态 链接 器 需要 的 
符号 链接 。 将 开发 时 使 用 的 库 安装 在 8SYSROOT/usrlib 目 录 下 ， 包 括 开发 
时 需要 的 符号 链接 及 静态 库 等 。 


(2) 动态 链接 器 


Glibc 亦 提供 了 加 载 共 享 库 的 工具 一 一 动态 加 载 器 。2.15 版 的 Glibc 提 供 
的 动态 加 载 器 为 ld-2.15.so， 其 符号 链接 是 ]d-linux.so.2， 也 安装 在 


$SYSROOT/ib 目 录 下 。 


人 


Glibc 为 应 用 程序 的 开发 提供 了 头 文件 ， 安 装 在 $SYSROOTAsvinclude 
目录 下 。 


(4) 工具 


Glibc 也 提供 了 一 些 可 执行 的 便利 工具 ， 这 类 工具 一 般 安装 在 sbin、 
usr/bin、usr/sbin 目 录 下 ， 比 如 用 来 转换 文件 字符 编码 的 工具 iconv， 在 
usr/lib/gconv 目 录 下 安装 了 工具 iconv 使 用 的 进行 字符 编码 转换 的 各 种 库 (如 


支持 GB18030 的 GB18030.so) ， 如 果 不 打 算 在 目标 系统 上 转换 文件 的 字符 
编码 ， 完 全 不 必 安 装 该 工具 。 另 外 还 有 比如 查看 共享 库 依 赖 的 工具 1dd， 创 
建 共享 库 缓 存 以 提高 共享 库 搜索 效率 的 ldconfig 程 序 等 。 


除 此 之 外 ，usr 目 录 下 还 有 支持 国际 化 、 时 区 设置 需要 的 文件 等 。 
(5 着 动 交 件 


Glibc 提 供 了 启动 文件 ， 包 括 crt1.o0、crti.o、crtn.o 等 ， 这 类 文件 在 编译 
链接 时 将 被 链接 恬 链 接 到 最 后 的 可 执行 文件 中 ，Glibc 将 其 安 猴 在 
$SYSROOT/usr/ib 目 录 下 。 


2.2.8 构建 完整 的 交叉 编译 需 


现在 目标 系统 的 C 库 已 经 构建 完成 ,我们 有 条 件 编 译 完整 的 编译 吴 了 
进入 GCC 的 编译 目录 ， 清 除 临 时 编译 的 文件 ， 重 新 配置 GCC， 与 第 一 阶段 
的 配置 并 无 本 质 区 别 ， 但 是 把 第 一 阶段 茶 掉 的 一 些 特性 打开 了 。 


vita@baisheng:/vita/build/gcc-builds$ rm -rf * 

vita@baisheng:/vita/build/gcc-builds$ ../gcc-4.7.2/configure \\ 
--prefix=$CROSS TOOL --target=$TARGET \ 
--with-sysroot=$SYSROOT \ 
--with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src \ 
--with-mpfr-lib=/vita/build/gcc-build/mpfr/src/.libs \ 
--enable-languages=c,c++ --enable-threads=posix 


注意 ， 这 次 是 编译 最 终 的 交叉 编译 器 ， 所 以 安装 在 $CROSS_TOOL 目 录 
下 ， 而 不 是 $CROSS_GCC_TMP 目 了 永 下 。 虽 然 GCC 文 持 多 种 编译 颖 ， 但 是 我 
们 只 需要 C 和 C++ 编译 人 器。 另外， 我 们 要 求 编 译 器 支持 posix 线 程 。 


在 配置 完成 后 ， 使 用 如 下 命令 编译 并 安 凑 : 


vita@baisheng:/vita/build/gcc-builds make 
vita@baisheng:/vita/build/gcc-builds$s make install 


最 终 的 交 义 编译 右 安 狠 的 主要 文件 如 下 : 


(1) 驱动 程序 


GCC 安 装 的 最 主要 的 是 交叉 编译 器 的 驱动 程序 ， 包 括 i1686-none-linux- 


gnu-gcc、i686-none-linux-gnu-g++ 等 。 


(2) 目标 系统 的 库 和 头 文件 


GCC 中 也 包含 了 一 些 用 于 目标 系统 的 运行 时 库 及 头 文件 ， 它 们 安装 在 
$CROSS_TOOL/i686-none-linux-gnu 目 录 下 。 在 该 目录 下 ， 子 目录 ]ib 存 放 包 
括 目标 系统 的 运行 时 库 以 及 供 目 标 系统 编译 程序 使 用 的 静态 库 ， 子 目录 
include 下 包含 开发 目标 系统 上 的 程序 需要 的 C++ 头 文件 。 


(3) helper program 


前 面 我 们 提 到 ，gcc 仅 仅 是 一 个 驱动 程序 ， 它 将 调用 具体 的 程序 完成 具 
体 的 任务 ， 这 些 程序 被 GCC 安装 在 libexec 目 永 下 ， 典 型 的 有 编译 器 cc1， 链 
接 过 程 调 用 的 collect2 等 。 


libexec 与 sbin/bin 目 录 下 存放 的 可 执行 文件 的 一 个 区 别 是 : sbin/bin 目 隶 
下 的 可 执行 文件 一 般 是 用 户 使 用 的 ， 而 libexec 目 录 下 的 可 执行 文件 一 般 是 
由 某 个 程序 或 工具 使 用 的 ， 所 以 一 般 称 为 "helper program"。 


(4) freestanding 实 现 文件 


前 面 我 们 提 到 ，C99 标 准 定义 了 两 种 实现 方式 : 一 种 称 为 "hosted 
implementation"， 支 持 全 部 C 标 准 ， 包 括 语言 标准 以 及 库 标 准 ;， 另外 一 种 
是 "freestanding implementation"。 在 lib 目 录 下 的 头 文件 即 为 "freestanding 
implementation" 实 现 标准 要 求 的 头 文件 。 


(5) 启动 文件 


与 C++ 相关 的 局 动 文件 在 GCC 中 ， 包 括 crtbegin.o、crtend.o 等 。 


讨论 完 C 库 和 编译 器 后 ， 我 们 看 到 ， 无 论 是 C 库 ， 还 是 GCC 都 各 目 安 效 
了 头 文件 、 运 行 库 ，GCC 还 安装 了 一 些 内 部 使 用 的 可 执行 程序 。 那 么 在 编 
译 程序 时 ，GCC 是 怎么 找到 这 些 文件 的 呢 ? 答案 就 是 GCC 内 部 定义 的 两 个 
环境 变量 LIBRARY_PATH 和 COMPILER_PATH。GCC 会 根据 用 户 的 一 些 配 
置 参 数 ， 包 括 --target、--with-sysroot 等 设置 这 些 环境 变量 的 值 。 我 们 可 以 在 
编译 程序 时 ， 使 用 参数 "-v" 查 看 这 两 个 变量 的 值 。 


Vita@baisheng:~$ i686-none-linux-gnu-gcc -Vv hello.c 


COMPILER PATH=/vita/cross-tool/libexec/gcc/i686-none-linux-gnu/4.6.1/:/vita/ 
cross-tool/libexec/gcc/i686-none-linux-gnu/4.6.1/:/vita/cross-tool/libexec/gcc/ 
i686-none-linux-gnu/:/vita/cross-tool/lib/gcc/i686-none-linux-gnu/4.6.1/:/vita/ 
cross-tool/lib/gcc/i686-none-linux-gnu/:/vita/cross-tool/lib/gcc/i686-none-linux- 
gnu/4.6.1/../../../../i686-none-linux-gnu/bin/ 

LIBRARY PATH=/vita/cross-tool/lib/gcc/i686-none-linux-gnu/4.6.1/:/vita/cross- 
tool/lib/gcc/i686-none-linux-gnu/4.6.1/../../../../i686-none-linux-gnu/lib/:/vita/ 
sysroot/lib/:/vita/sysroot/usr/lib/ 


比如 库 的 搜索 路 径 ， 根 据 LIBRARY_PATH 的 定义 ， 显 然 ， 既 包括 GCC 
装 的 库 的 路 径 /vita/cross-tooyi686-none-linux-gnUlib， 又 包括 Glibc 安 朔 的 
et : 


2.2.9 定义 工具 链 相 天 的 环境 变量 


GNU Make 使 用 了 一 些 隐 示 的 预定 义 变 量 ， 并 且 这 些 变量 都 有 对 
应 的 默认 值 。 如 CC 代表 编译 器 ， 默 认 值 是 程序 cc， 这 也 是 为 什么 
Linux 各 个 发 行 版 中 一 般 都 有 一 个 符号 连接 "cc" 指向 真正 的 编译 器 的 原 
。 再 比如 AR 代 表 汇 编 器 ， 默 认 值 为 ar。 读 者 可 以 使 用 下 面 的 命令 输 
出 make 的 数据 库 ， 进 一 步 查看 make 数 据 库 中 的 信息 ， 比 如 查看 交叉 编 
译 环 境 中 的 编译 器 。 


Vita@baisheng:~$ make -p | grep CC 


CC = i1686-none-linux-gnu-gcc 
CPP’ 三 (CEC) SE 


这 些 隐 示 的 预定 义 变 量 可 以 通过 环境 变量 覆盖 ， 或 者 在 makefile 中 
显示 重新 定义 。 为 了 避免 在 编译 每 一 个 软件 包 时 ， 都 需要 显示 指定 使 
用 我 们 构建 的 交叉 工具 链 ， 我 们 在 环境 变量 中 定义 编译 过 程 使 用 的 相 
关 变 量 。 我 们 将 相关 变量 定义 在 /home/vita/.bashrc 中 ， 确 保 在 每 次 切换 
到 vita 用 户 时 ， 这 些 变量 定义 自动 生效 。 


/home/vita/ .bashrc 


export CC="$TARGET-gcc" 

export CXX="$TARGET-g++" 
export AR="$TARGET-ar" 

export AS="$TARGET-as" 

export RANLIB="S$TARGET-ranlib" 
export LD="S$TARGET-1d" 

export STRIP="$TARGET-strip" 


在 后 面 安装 编译 程序 时 ， 一 般 我 们 均 通 过 给 make 传 递 变量 
DESTDIR 指 定 make 将 它们 安装 到 目标 系统 的 根 文 件 系统 下 ， 即 
$SYSROOT 目 了 永 下。 为 了 避免 每 次 都 需要 指定 DESTDIR 变 量 ， 我 们 也 


在 .bashrc 中 定义 这 个 变量 。 


/home/vita/ .bashrc 


export DESTDIR=$SYSROOT 


为 了 使 设置 生效 ， 定 义 变量 后 需要 退出 并 重新 切换 到 vita 用 户 。 


注意 ， 如 果 需 要 重新 构建 交 义 编译 工具 链 ， 在 构建 前 ， 要 注释 挥 
这 一 节 的 变量 定义 ， 在 构建 完成 工具 链 后 再 重新 启用 这 里 的 变量 定 
Ys 


2.2.10” 封 闻 “ 交 叉 ”pkg-config 


在 GNU 中 大 部 分 的 软件 都 使 用 Autoconf 配 置 ，Autoconf 通 常 借助 工具 
pkg-config 去 获取 将 要 编译 的 程序 依赖 的 共享 库 的 一 些 信 息 ， 比 如 库 的 头 文 
件 存 放 在 哪个 目录 下 ， 共 享 库存 放 在 哪个 目录 下 以 及 链接 哪些 共享 库 等 ， 
我 们 将 其 称 为 库 的 元 信息 。 通 常 ， 这 些 信息 都 被 保存 在 一 个 以 软件 包 的 名 
称 命 名 ， 并 以 ".pc" 作 为 扩展 名 的 文件 中 。 而 pkg-config 会 到 特定 的 目录 下 导 
找 这 些 pc 文件 ， 一 般 而 言 ， 其 首先 搜索 环境 变量 PKG_CONFIG_PATH 指 定 
的 目录 ， 然 后 搜索 默认 上 路径， 一般 
是 /usr/lib/pkgconfig、/usr/share/pkgconfig、/usr/locallib/pkgconfig 等 。 显 然 ， 
使 用 环境 变量 PKG_CONFIG_PATH 不 能 满足 我 们 的 要 求 。 因 为 在 交叉 编译 
环境 中 ， 我 们 是 不 能 允许 正在 编译 的 程序 链接 到 宿主 系统 的 库 上 的 ， 也 就 
是 说 ， 我 们 除了 告诉 pkg-config 到 目标 系统 的 文件 系统 中 寻找 外 ， 还 要 禁止 
它 搜索 默认 的 得 主 系统 的 路 径 。 而 另外 一 个 环境 变量 
PKG_CONFIG_LIBDIR 可 以 满足 我 们 这 个 需求 ， 一 旦 设置 了 
PKG_CONFIG_LIBDIR， 其 将 取代 pkg-config 默 认 的 搜索 路 径 。 因 此 ， 在 交 
又 编译 时 ， 这 两 个 变量 的 设置 如 下 : 


/home/vita/ .bashrc 


unset PKG CONFIG PATH 
export PKG CONFIG LIBDIR=$SYSROOT/usr/1ib/pkgcontfig:\ 
$SYSROOT/usr/share/pkgcontftig 


注意 ”如 果 需 要 重新 构建 交叉 编译 工具 链 ， 在 构建 前 ， 也 需要 注释 掉 
此 处 的 变量 定义 ， 在 构建 完成 工具 链 后 再 重新 局 用 这 里 的 变量 定义 。 


除了 pkg-config 寻 找 pc 文件 的 搜索 路 径 需 要 调整 外 ， 从 pc 文件 中 获取 的 
cflags 和 libs 也 需要 追加 sysroot 作 为 前 级 。 因 此 ， 这 里 我 们 包装 一 下 host 系 统 
的 pkg-config， 将 为 交叉 编译 定制 的 pkg-config 放 在 $SYSROOTbin 下 。 


/vita/cross-tool/bin/pkg-config : 


#!/bin/bash 
HOST PKG CFG=/usr/bin/pkg-config 


EE [| SSYSROOT 3 then 
echo "Please make sure you are in cross-compile environment!" 
exit 1 


fi 


$HOST PKG CFG --exists S$* 

if [ $? -ne 0 ]; then 
exit 1 

fi 


if $HOST PKG CFG $* | sed -e "s/-I/-I\/vita\/sysroot/g;\ 
s/-L/-L\/vita\/sysroot/g" 
then 
exit 0 
else 
exit 1 
fH 


并 为 pkg-config 增 加 执行 权限 : 


vita@baisheng:/vita/cross-tool/bins$ chmod a+x pkg-confi 


下 面 是 宿主 系统 目 身 的 pkg-config 获 得 的 libmount 库 的 --cflags 和 --libs: 


vita@baisheng:~$ /usr/bin/pkg-config --cflags --libs mount 
-I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/uuid -lmount 


下 面 是 经 过 我 们 包装 的 pkg-config 得 的 libmount 库 的 --cflags 和 --libs: 


vita@baisheng:~$ pkg-config --cflags --libs mount 
-I/vita/sysroot/usr/include/libmount 
-I/vita/sysroot/usr/include/blkid 
-I/vita/sysroot/usr/include/uuid -lmount 


汰 ， 经 过 我 们 包 闭 的 pkg-config 不 再 到 宿主 系统 的 文件 系统 下 寻找 依 
赖 的 库 ， 而 是 到 目标 系统 的 根 文件 系统 下 去 寻找 依赖 的 共享 库 及 头 文件 


和 。 
地 


2.2.11 关于 使 用 ]ibtool 链 接 库 的 讨论 


GNU 中 的 大 部 分 软件 包 都 使 用 libtool 处 理 库 的 链接 。 通 常 ， 大 部 分 的 软 
件 在 包 发 布 时 都 已 经 包含 了 libtool 所 需 的 脚本 工具 等 。 但 是 如 果 一 旦 准备 使 
用 autoconf、automake 重 新 生成 编译 脚本 ， 且 这 些 脚本 中 包 人 对 了 libtool 提 供 
的 M4 宏 ， 则 需要 安装 libtool。 可 使 用 如 下 命令 安装 ]ibtool 。 


root@baisheng:~# apt-get install libtool 


在 交叉 编译 环境 中 使 用 libtool 处 理 库 的 链接 时 ， 依 然 还 有 个 不 大 不 小 的 
问题 ， 如 同 pkg-config 的 廊 烦 一 样 ， 如 果 使 用 答 主 系统 的 libtool， 那 么 编译 
库 时 生成 的 库 的 la 文件 中 ， 记 录 库 本 身 安装 的 位 置 以 及 依赖 库 的 安装 位 置 的 
路 径 将 依然 指向 宿主 系统 的 根 文 件 系统 ， 比 如 一 个 典型 的 la 文件 : 

dependency libs=' /usr/lib/libxcb.la /usr/lib/libxXau.l1a' 
libdir=' /usr/l1ib' 

而 实际 上 ， 目 标 系 统 的 根 文 件 系 统 在 $6SSYSROOT 下 。 显 然 ， 如 果 使 用 
libtool 链 接 ， 将 会 找 错 库 的 安装 位 置 。 


我 们 可 以 修改 宿主 系统 的 libtool， 使 其 在 交叉 编译 环境 下 能 够 创建 合适 
的 la 文件 ;或 者 直接 修改 la 文件 ， 将 类 似 "/usr/lib/*" 的 路 径 调 整 
为 "9SYSROOTVusrlib/*"; 或 者 如 pkg-config 一 样 ， 封 装 一 个 libtool。 但 是 我 
们 采用 更 简单 的 方式 ， 使 用 如 下 命令 将 la 文件 删除 : 


find $SYSROOT -name "x.1a" -exec rm -f '{}' \; 


删除 库 的 la 文件 后 ， 链 接 相应 的 库 时 将 不 再 使 用 libtool 去 寻找 库 的 位 


， 而 是 依靠 链接 万 去 寻找 库 的 位 置 。 虽 然 libtool 不 建议 这 样 做 ， 但 这 样 做 
商 单 ， 且 不 容易 发 生 错误 ， 因 此 ， 后 续 我 们 采用 这 种 方法 。 


2 人 局 动人 后 


局 动 代码 是 工具 链 中 C 库 和 编译 紫 部 提供 了 的 重要 部 分 之 一 ， 但 是 由 于 
应 用 程序 员 很 少 接触 它们 ， 因 此 非常 容易 引起 程序 员 的 困惑 ， 所 以 我 们 特 
将 其 单独 列 出 ， 使 用 一 点 篇 幅 加 以 讨论 。 


不 知 读者 坪 否 留意 过 这 个 问题 : 无 论 征 在 DOS 下 、Windows 下 ， 还 是 在 
Linux 操 作 系统 下 ， 程 序 员 使 用 C 语 言 编程 时 ， 几 乎 所 有 程序 的 入 口 函数 都 
征 main， 这 是 因为 启动 代码 的 存在 。 在 "hosted environment" 下 ， 应 用 程序 运 
行 在 操作 系统 之 上 ， 程 序 局 动 前 和 退出 前 需要 进行 一 些 初始 化 和 善后 工 
作 ， 而 这 些 工 作 与 "hosted environment" 密 切 相 关 ， 并 且 是 公共 的 ， 不 属于 应 
用 程序 范畴 的 事情 ， 这 些 应 用 程序 员 无 需 关 心 。 更 重要 的 一 点 是 ， 有 些 初 

台 化 动作 需要 在 main 函 数 运行 前 完成 ， 比 如 C++ 全 局 对 象 的 构造 。 有 些 操作 
征 不 能 使 用 C 语 言 完 成 的 ， 必 须要 使 用 汇编 指令 ， 比 如 栈 的 初始 化 。 于 十 编 
译 右 和 C 库 将 它们 抽取 出 来 ， 放 在 了 公共 的 代码 中 。 


这 些 公共 代码 被 称 为 启动 代码 ， 其 实 不 只 是 程序 启动 时 ， 也 包括 在 程 
序 退 出 时 执行 的 一 些 代 码 ， 我 们 统称 它们 为 启动 代码 ， 并 将 局 动 代码 所 在 
的 文件 称 为 局 动 文 件 。 对 于 C 语 言 来 说 ，Glibc 提 供 局 动 文件 。 显 然 ， 对 于 
C++ 语言 来 说 ， 因 为 局 动 代码 是 和 语言 密切 相关 的 ， 所 以 其 局 动 代码 不 在 C 
库 中 ， 而 由 GCC 提 供 。 这 些 启动 文件 以 "crt”( 可 以 理解 为 C RunTime 的 缩 
与 ) 开头 “以 "go" 结 必 。 


我 们 查看 可 执行 程序 hello 的 入 口 函 数 : 


root@baisheng:~/demo# readelf -h hello | grep Entry 
Entry point address: 0x80482f0 


根据 ELE 的 头 可 见 ， 可 执行 文件 hello 的 入 口 地 址 为 0x80482f0。 但 该 地 
址 对 应 的 函数 是 main 吗 ? 


root@baisheng:~/demo# readelf -s hello | grep 80482f0 
61: 080482f0 0 FUNC GLOBAL DEFAULT 13 8tart 


结果 显然 让 我 们 很 失望 ， 可 执行 文件 的 入 口 不 是 我 们 熟悉 的 main 函 
数 ， 而 是 一 个 陌生 的 _start 函 数 ， 而 且 和 我 们 的 职业 直 常 ， 这 个 函数 的 定义 
很 像 汇编 语言 的 函数 名 。 我 们 再 来 看 一 下 可 执行 文件 hello 的 代码 段 的 起 始 
地 址 : 


root@baisheng:~/demo# readelf -S hello 
There are 30 section headers, starting at offset 0x1198 : 
Section Headers: 

[Nr] Name Type Addr OEE Size 


[13] text PROGBITS 080482f0 0002f0 0001b8 


根据 代码 段 的 起 始 地 址 可 见 ，hello 的 代码 段 的 最 开头 的 函数 确实 是 函 
数 _start， 而 不 是 我 们 熟悉 的 main 函 数 。 那 么 main 函 数 在 哪里 呢 ? 


root@baisheng:~/demo# readelf -s hello | grep main 
64: 080483fc 38 FUNC GLOBAL DEFAULT 13 main 


我 们 做 个 减法 运算 : 


0x080483fc - 0x080482f0 = Oxl0c = 268 


也 就 是 说 ， 在 代码 段 中 ， 偏 移 268 字 市 处 才 是 main 函 数 的 代码 ， 代 码 段 
的 前 268 字 菠 都 是 启动 代码 ， 当 然 ， 程 序 局 动 时 的 局 动 代码 不 仅 限于 这 268 
字 方 ， 因 为 钞 数 _start 中 可 能 还 会 调用 C 库 中 的 一 些 函 数 。 


如 果 用 户 的 程序 中 ， 没 有 明确 指明 使 用 自己 定义 的 局 动 代码 ， 那 么 链 
接 器 将 目 动 使 用 C 库 和 C 编 译 右 中 提供 的 局 动 代码 。 链 接 紫 将 范 数 "_start" 作 
为 ELF 文 件 的 默认 入 口 函 数 。 男 数 _start 的 相关 代码 如 下 : 


glibc-2.15/sysdeps/i386/elf/start.s 


_ Start:: 
popl %esi /* Pop the argument count. */ 
mov]1] %esp, Secx /* argv starts just at the current stack top.*/ 


andl] S$Oxfffffff0, %esp 
pushl %Seax /* Push garbage because we allocate 
28 more bytes. */ 


pushl %esp 


pushl Sedx /* Push address of the shared library 
termination function. */ 


/* Push address of our own entry points to .fini and .init. */ 
pushl $_ libc csu fini 
BUushl, % Libe eu init 


pushl Secx /* Push second argument: argv. */ 
pushl S$%esi /* Push first argument: argc. */ 


pushl $BP SYM (main) 


/* Call the user's main function, and exit with its value. 
But let the libc call main. */ 
call BP SYM (_ libc start main) 


_start 函 数 先 作 了 一 些 初 始 化 ， 接 着 承 是 调用 _libc_start_main 压 栈 参 
数 ， 包 括 程 序 进入 main 函 数 之 前 的 初始 化 函数 _libc_csu_init、 退 出 时 可 能 
执行 的 兽 后 函数 _libc_csu_fini 以 及 main 函 数 的 参数 ， 最 后 调用 


_ libc_ start main ° 


LIDGSD, LES/CBU/ LIDG- Blart. Ge 


STATIG Tnt TIDG START MARTIN (,...) 


人 


5 
(*init) (argc, argv, _ environ MAIN AUXVEC PARAM),; 


result = main (argc, argv, _ environ MAIN AUXVEC PARAM),; 


进入 函数 _libc_start_main 后 ， 将 调用 函数 _ libc_csu_init 等 初始 化 函数 
进行 各 种 初始 化 操作 、 准 备 程序 运行 环境 ， 最 后 才 进 入 我 们 就 知 的 main 范 
尖 o 


函数 _start 包 含 在 司 动 文 件 crt1.o 中 。 根 据 局 动 文件 crt1.o 的 符号 表 也 可 看 


HY 


vita@baisheng:/vitas$ readelf -s /vita/sysroot/usr/lib/crtl.o 


18: 00000000 0 FUNC GLOBAL DEFAULT 2 _start 


通过 前 面 的 简要 分 析 ， 我 们 直观 地 感受 到 了 所 谓 “ 启 动 代码 ”的 意义 。 
函数 _start 才 是 第 一 个 从 "hosted environment" 进 入 到 应 用 程序 时 运行 的 第 一 
个 函数 ， 且 名副其实 的 入 口 函 数 。 从 系统 的 角度 看 ，main 函 数 与 普通 函数 
无 异 ， 并 不 是 什么 真正 的 入 口 画 数 ，main 只 是 程序 员 的 入 口 函数 。 因 此 ， 
通过 更 改 启动 代码 ， 这 个 程序 员 的 入 口 函数 也 完全 可 以 使 用 其 他 的 函数 名 
称 而 不 是 什么 main， 比 如 MFC 中 就 不 用 main 这 个 名 字 。 


在 链接 时 ，gcc 使 用 内 置 的 spec 文 件 来 控制 链接 的 启动 文件 。 编 译 时 ， 
可 以 通过 给 gcc 传 递 参数 -specs=file 来 覆盖 gcc 内 置 的 spec 文 件 。 我 们 可 以 传 
递 参数 -dumpspec 来 查看 gcc 内 置 的 spec 文 件 规定 链接 时 链接 哪些 启动 文件 : 


vita@baisheng:~$ i686-none-linux-gnu-gcc -dumpspec 


*endfile: 
$s{0fast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s)} 
${mpc32:crtprec32.0%s} 

${mpc64:crtprec64.0%s} 

S${mpc80:crtprec80.0%s} 

$s{shared|pie:crtendSs.o%s; :crtend.o%s} 

Grtn os 


*startfile: 


s{!shared: %{pg|p|profile:gcrtl1.o%s;pie:Scrt1l.o0%s; :crt1.o%s}} 
os 


s{static:crtbeginT.ogssji;shared|pie:crtbeginS .ossji :crtbegin.ogss } 


当然 ， 编 译 时 也 可 以 根据 实际 情况 传递 参数 如 -nostartfiles、-nostdlib、- 
ffreestanding 等 给 链接 器 ， 告 诉 链接 右 不 要 链接 系统 中 提供 的 局 动 代码 ， 而 
是 使 用 自己 程序 中 提供 的 。 


最 后 ， 让 我 们 以 一 个 小 例子 ， 结 束 本 划 。 回 顾 上 面 的 函数 
_ libc_start_main， 在 其 调用 main 函 数 前 ， 局 动 代码 中 的 函数 


_jlibc_start_main 将 调用 init 函 数 ， 而 _start 传 递 给 _jlibc_start_main 的 init 函 数 


指针 指向 的 是 _libc_csu_init: 


glibc-2.15/csu/elf-init.c: 


void _libc csu init (int argc; char **argv,; char **envp) 


{ 


#ifndef LIBC NONSHARED 


/* For static executables, preinit happens right before init. */ 
const size t size = preinit array end - 
_ Ppreinit array start; 
SIZe, 起 六 5 
for (i = 0; i < size; i++) 
(* preinit array. start [i]) (argc argv; envp) :; 
#endif 
nid 
const size t size = init array end - initb: array Blarts 
For (BEzEt 二 生 0F 下 BLZ6F Be) 
(* init array start [i]) (large, argv; envp); 


根据 函数 可 见 ，_libc_csu_init 将 先后 调用 
段 ".preinit_array"、".init_array" 中 包含 的 函数 指针 指向 的 函数 。 因 此 ， 如 果 
打算 在 程序 执行 main 函 数 前 或 者 在 动态 库 被 加 载 时 做 点 什么 ， 那 么 我 们 可 
以 定义 一 个 函数 ， 并 告诉 链接 器 将 函数 指针 存储 到 
段 ".preinit_array" 或 ".init_array" 中 。 示 例 代 码 如 下 : 


£06C 
#include <stdio.h> 


void myinit (int argc, char **argv, char **envp) 


{ 


printf("%s\n", _ FUNCTION ); 
} 
_ attribute ((section(".init array"))) typeof (myinit) * myinit = 
myinit; 


void test () 


{ 
} 


peintf ("aN FUNCTION } 


Ba 
#include <stdio.h> 


void main() 


{ 


printf ("Enter main./n"); 
test () ; 


我 们 通过 关键 字 "__attribute_((section(".init_array")))" 指 定 链接 古 将 函 
数 myinit 的 地 址 放置 到 段 ".init_array" 中 ， 那 么 在 库 libfoo 被 加 载 时 ， 画 数 


myinit 会 被 _libc_csu_init 调 用 。 


使 用 如 下 命令 编译 并 运行 程序 : 


root@baisheng:~/demo# gcc -shared -fPIC foo.c -Oo libfoo.so 
root@baisheng:~/demo# gcc bar.c -o bar -L./ -lfoo 
root@baisheng:~/demo# LD LIBRARY PATH=./ ./bar 

myinit 

Enter main. 

test 


根据 程序 bar 的 输出 可 见 ， 画 数 myinit 在 进入 函数 main 之 前 就 被 调用 
了 。 也 束 是 说 ， 库 ]ibfoo 在 加 载 时 ， 画 数 myinit 忠 被 启动 代码 调用 了 。 


第 3 对 ”构建 内 核 


内 核 的 构建 系统 kbuild 基 于 GNU Make， 是 一 套 非 常 复杂 的 系统 。 我 们 
本 无 意 着 太 多 笔墨 来 分 析 kbuild， 因 为 作为 开发 者 可 能 永远 不 需要 去 改动 内 
核 映 像 的 构建 过 程 ， 但 是 了 解 这 一 过 程 ， 无 论 是 对 学 习 内 核 ， 还 是 进行 内 
核 开 发 都 有 诸多 帮助 。 所 以 在 构建 内 核 之 前 ， 本 章 首 和 完 讨 论 了 内 核 的 构建 
过 程 。 


对 于 编译 内 核 而 言 ， 一 条 make 命 令 就 足够 了 。 因 此 ， 构 建 内 核 最 困难 
的 地 方 不 是 编译 ， 而 是 编译 前 的 配置 。 配 置 内 核 时 ， 通 常 我 们 都 能 找到 一 
些 参考 。 比 如 ， 对 于 桌面 系统 ， 可 以 参考 主流 发 行 版 的 内 核 配 置 。 但 是 ， 
这 些 发 行 版 为 了 能 够 在 更 多 的 机 器 上 运行 ， 几 乎 选择 了 全 部 的 配置 选项 ， 
编译 了 全 部 的 驱动 ， 不 仅 增 加 了 内 核 的 体积 ， 还 降低 了 内 核 的 运行 速度 。 
再 比如 ， 对 于 舱 入 式 系统 ，BSP (Board Support Package) 中 通常 也 提供 内 
核 ， 但 他 们 通常 也 仅 是 个 可 以 工作 的 内 核 而 已 。 显 然 ， 如 果 要 一 个 占用 空 
间 更 小 、 运 行 更 快 的 内 核 ， 就 需要 开发 人 员 手 动 配置 内 核 。 而 且 ， 也 确实 
存在 着 在 某 些 情况 下 ， 我 们 找 不 到 任何 合适 的 参考 ， 这 时 我 们 只 能 以 手动 
方式 从 零 开 始 配置 。 


但 是 ， 面 对 内 核 中 成 干 上 万 的 配置 选项 ， 开 发 人 员 通 第 不 知 从 何 下 
手 。 但 正 所 谓 万 事 开 头 难 ， 一 旦 迈 过 了 这 个 坎 ， 读 者 吏 不 会 在 内 核 前 望 而 
却步 。 因 此 ， 在 本 章 中 ， 我 们 摸 着 石头 过 河 ， 带 领 读 者 以 手动 的 方式 配置 
内 核 。 


在 内 核 启动 的 最 后 ， 内 核 要 从 根 文 件 系统 加 载 用 户 空间 的 程序 从 而 转 
入 用 户 空 间 。 因 此 ， 在 本 章 的 最 后 ， 我 们 准备 了 一 个 基本 的 根 文件 系统 来 
配合 内 核 的 局 动 。 我 们 也 采用 手动 的 方式 构建 这 个 根 文件 系统 ， 通 过 手动 
的 方式 ， 读 者 将 会 更 透彻 地 了 解 到 动 辑 儿 个 GB 的 根 文件 系统 是 如 何 组 织 和 
安排 的 。 


3.1 ”内核 上 映像 的 组 成 


在 讨论 内 核 构建 前 ， 我 们 先 来 简 单 了 解 一 下 内 核 映 像 的 组 成 ， 如 图 3-1 
Es 


| setwpon | DS 
~ 1 par J ~ : 
| | | uncompressed | uncompressed 
~ | :| (part1) |: (part 1 


vmlinux > :| vmlinux.bin.gz | 王 一 和 | vmlinux.bin.gz |: vmlinux.bi 


n.gz 


part 1) 
A | uncompressed |: uncompressed 

| : | ar2 | | (part 2) 

a iluncompressed || -二 | | 
| (part2) | i Vmlinux.bin 一 bzlmage 


图 3-1 内 核 映 像 bzImage 的 组 成 


如 果 将 内 核 的 映像 比 作 航天 絮 ， 则 setup.bin 部 分 就 类 似 于 火箭 的 一 级 推 
进 子 系统 。 最 初 ， 这 部 分 负责 将 内 核 加 载 进 内 存 ， 并 为 后 面 内 核 保 护 模式 
的 运行 建立 基本 的 环境 。 但 后 来 加 载 内 核 的 功能 被 分 离 到 Bootloader 中 ， 
setup.bin 则 退化 为 辅助 Bootloader 将 内 核 加载 到 内 存 。 


紧 接 着 ， 包 围 在 32 位 保护 模式 部 分 外 的 是 非 解压 缩 部 分 。 这 部 分 可 以 
看 作 是 火箭 的 二 级 推进 子 系统 ， 负 贡 将 压缩 的 内 核 解压 到 合适 的 位 置 ， 并 
进行 内 核 重 定位 ， 在 完成 这 个 环节 后 ， 其 从 内 核 映 像 脱离 。 


后 是 内 核 的 32 位 保护 模式 部 分 vmlinux。 这 部 分 相当 于 航天 器 的 有 效 
载 集 ， 即 类 似 于 最 后 运行 的 卫星 或 者 宇宙 飞船 ， 只 有 这 部 分 最 后 留 在 轨道 
内 (内 存 中 ) 运行 。 内 核 构 建 时 ， 将 对 有 效 载荷 vmlinux 进 行 压缩 ， 然 后 与 
二 级 推进 系统 闭 配 为 vmlinux.bin 。 


下 面 我 们 束 来 看 看 内 核 映 像 的 各 个 组 成 部 分 


3.1.1 一 级 推进 系统 


setup.bin 


在 进行 内 核 初始 化 时 ， 需 要 一 些 信 息 ， 如 显示 信息 、 内 存 信息 曾 
这 些 信息 由 工作 在 实 模式 下 的 setup.bin 通 过 BIOS 获 取 ， 保 存在 内 核 中 
的 变量 boot_params 中 ， 变 量 boot_params 是 结构 体 boot_params 的 一 个 实例 。 


如 setup.bin 中 收集 显示 信息 的 代码 如 下 : 


人 


linux-3.7.4/arch/x86/boot/video.c: 


static void store video mode (void) 


{ 


struct biosregs ireg, oreg; 


initregs (&ireg) ; 
iEegsal 二 00 
intcall (0x10, &ireg, &oreg); 


boot params.screen info.orig video mode 
boot params.screen info.orig video page 


oreg.al & 0x7f; 
oreg .bh; 


store video_mode 首 先 调用 函数 intcall 获 取 显 示 方 面 的 信息 ， 并 将 其 保 


存在 boot_params 的 screen_info 中 。intcall 是 调用 BIOS 中 断 的 封 闻 ，0x10 是 
BIOS 提 供 的 显示 服务 (Video Service) 的 中 断 号 ， 代 码 如 下 : 


但 


linux-3.7.4/arch/x86/boot/bioscall.s: 


intcall; 
/* Self-modify the INT instruction. Ugly, but works. */ 
cmpb Sals 3E 


je 1f 

movb Sal;: 3£ 

jmp 1f /* Synchronize pipeline */ 
1 

.byte Oxcd /* INT opcode */ 
3 .byte 0 


在 代码 中 我 们 并 没有 看 到 熟悉 的 调用 BIOS 中 断 的 身影 ， 如 "int$0x10"， 


日 是 我 们 看 到 了 一 个 特殊 的 字符 一 一 0xcd。 正 如 其 后 面 的 注释 所 言 ，0xcd 


束 是 x86 汇 编 指 令 INT 的 机 融 码 ， 如 表 3-1 所 示 。 


表 3-1 x86 INT 指令 说 明 (部 分 ) 


天 纹 编 三 局 
了 呈 本 Re | 


NG 


根据 x86 的 INT 指 令 说 明 ，0xcd 后 面 跟着 的 1 字 节 就 是 BIOS 中 断 号 ， 这 


忠 古 上 面 代码 中 标号 为 3 处 分 配 1 字 市 的 目的 。 


二 


1 ， 


在 函数 intcall 的 开头 ， 首 先 比较 寄存 器 al 中 的 值 与 标号 3 处 占用 的 1 字 
若 相 等 则 直接 向 前 跳 转 至 标号 1 处 ， 否 则 将 寄存 右 al 中 的 值 复制 到 标号 3 


处 的 1 个 字 市 空间 。 那 么 寄存 右 al 中 保存 的 古 什 么 呢 ? 


在 默认 情况 下 ，GCC 使 用 栈 来 传递 参数 。 但 是 我 们 可 以 使 用 关键 
字 "_ attribute (regparm(n))" 修 饰 画 数 ， 或 者 通过 向 GCC 传 递 命令 行 参数 "- 
mregparm=n" 来 指定 GCC 使 用 寄存 器 传递 参数 ， 其 中 n 表 示 使 用 寄存 器 传递 
参数 的 个 数 。 在 编译 setup.bin 时 ，kbuild 使 用 了 后 者 ， 编 译 脚本 如 下 所 示 : 


linux-3.7.4/arch/x86/boot/Makefile.: 
KBUILD CFLAGS := 4s -Mregparm=3 ， 
如 此 ， 画 数 的 第 一 个 参数 通过 寄存 器 eax/ax 传 递 ， 第 二 个 参数 通过 


ebx/bx 传 递 ， 等 等 ， 而 不 是 通过 栈 传递 了 了。 因此， 上面 的 寄存 器 al 中 保存 的 
是 函数 intcall 的 第 一 个 参数 ， 即 BIOS 中 断 号 。 


在 完成 信息 收集 后 ，setup.bin 将 CPU 切换 到 保护 模式 ， 并 跳 转 到 内 核 的 
保护 模式 部 分 执行 。 如 我 们 前 面 讨论 的 ，setup.bin 作 为 一 级 推进 系统 ， 即 将 
结束 历史 使 命 ， 所 以 内 核 将 setup.bin 收 集 的 保存 在 setup.bin 的 数据 段 的 变量 
boot_params 复 制 到 vmlinux 的 数据 段 中 。 


但 是 随 着 新 的 BIOS 标 准 的 出 现 ， 尤 其 古 EFI 的 出 现 ， 为 了 支持 这 些 新 标 
准 ， 开 发 者 们 制定 了 32 位 启动 协议 (32-bit boot protocol) 。 在 32 位 启动 协 
议 下 ， 由 Bootloader 实 现 收集 这 些 信息 的 功能 ， 内 核 启动 时 不 再 需要 站 先 运 
行 实 模式 部 分 ( 即 setup.bin) ， 而 是 直接 跳 转 到 内 核 的 保护 模式 部 分 。 
此 ， 在 32 位 启动 协议 下 ， 不 再 需要 setup.bin 收 集 内 核 初 始 化 时 需要 的 相关 信 
息 。 但 是 这 是 否 意 味 着 可 以 彻底 放弃 setup.bin 呢 ? 


事实 上 ， 除 了 收集 信息 功能 外 ，setup.bin 被 忽略 的 另 一 个 重要 功能 就 是 
负责 在 内 核 和 Bootloader 之 间 传 递 信息 。 例 如 ， 在 加 载 内 核 时 ，Bootloader 
需要 从 setup.bin 中 获取 内 核 是 否 是 可 重 定位 的 、 内 核 的 对 齐 要求 、 内 核 建议 
的 加 载 地 址 等 。32 位 启动 协议 约定 在 setup.bin 中 分 配 一 块 空间 用 来 承载 这 些 
言 息 ， 在 构建 映像 时 ， 内 核 构 建 系统 需要 将 这 些 信息 写 到 setup.bin 的 这 块 空 
间 中 。 所 以 ， 虽 然 setup.bin 已 经 失去 了 其 以 往 的 作用 ， 但 还 不 能 完全 放弃 ， 
其 还 要 作为 内 核 与 Bootloader 之 间 传 递 数据 的 桥梁 ， 而 且 还 要 照顾 到 某 些 不 
能 使 用 32 位 启动 协议 的 场合 。 


3.1.2 ”二 级 推进 系统 一 一 内 核 非 压缩 部 分 


内 核 的 保护 模式 部 分 古 经 过 压缩 的 ， 因 此 运行 前 需要 解压 缩 ， 但 
征 谁 来 负责 内 核 映 像 的 解压 呢 ? 解 铃 还 须 系 铃 人 ， 既 然 内 核 在 构建 时 
目 己 压缩 了 自己， 当然 解压 缩 也 要 由 内 核 映 像 目 己 完成 。 


内 核 在 压缩 的 映像 外 包围 了 一 部 分 非 压缩 的 代码 ，Bootloader 在 加 
载 内 核 映 像 后 跳 转 至 外 围 的 这 上段 非 压 缩 部 分 。 这 些 没有 经 过 解压 缩 的 
指令 可 以 直接 送 给 CPU 执 行 ， 由 这 段 CPU 可 执行 的 指令 负责 解压 内 核 
的 压缩 部 分 。 


除了 解压 以 外 ， 非 压缩 部 分 还 负责 内 核 重 定位 。 内核 可 以 配置 为 
可 重 定位 的 (relocatable) ， 所 谓 可 重 定位 即 内 核 可 以 被 Bootloader 加 
载 到 内 存 任何 位 置 。 但 是 在 链接 内 核 时 ， 链 接 夯 需要 假定 一 个 加 载 地 
址 ， 然 后 以 这 个 假定 地 址 为 参考 ， 为 各 个 符号 分 配 运 行 时 地 址 。 显 
然 ， 如 果 加 载 地 址 和 链接 时 假定 的 地 址 不 同 ， 那 么 需要 对 符号 的 地 址 


进行 重新 修订 ， 这 就 是 内 核 重 定位 。 


内 核 非 压缩 部 分 工作 在 保护 模式 下 ， 其 占用 的 内 存在 完成 使 命 后 
将 会 被 释放 。 


3.1.3 ”有戏 载 何 vmlinux 


在 编译 时 ，kbuild 分 别 构建 内 核 各 个 子 目录 中 的 目标 文件 ， 然 后 
将 它们 链接 为 vmlinux。 为 了 缩小 内 核 体 积 ，kbuild 删 除了 vmlinux 中 一 
些 不 必要 的 信息 ， 并 将 其 命名 为 vmlinux.bin， 最 后 将 vmlinux.bin 压 缩 
为 vmlinux.bin.gz。 在 默认 情况 下 ， 内 核 使 用 gzip 压 缩 ， 当 然 也 可 以 在 
配置 时 指定 使 用 lzma 等 压缩 格式 。gzip 的 压缩 比 相 对 较 小 ， 但 是 压缩 
速度 相对 较 快 。 


那么 为 什么 内 核 要 进行 压缩 呢 ? 


1) 最 初 ， 因 为 在 某 些 体系 架构 上 ， 特 别 是 i386， 系 统 启动 时 运行 
于 实 模式 状态 ， 可 以 寻 址 空间 只 能 在 1MB 以 下 ， 如 有 果 内 核 矿 寸 过 大 ， 
将 无 法 正 滑 加 载 ， 因 此 ， 对 内 核 进行 了 压缩 。 在 内 核 加 载 完毕 后 ， 
CPU 切换 到 保护 模式 ， 可 以 寻 址 更 大 的 地 址 空间 ， 于 十 束 可 以 将 压缩 
过 的 内 核 展开 了 。 


2) 男 外 一 个 原因 是 ，2.4 及 更 早 版 本 的 内 核 ， 需 要 可 以 容纳 在 一 
张 软盘 上 ， 上 所 以 内 核 也 要 进行 压缩 。 


以 上 都 是 历史 原因 了 ， 如 今 有 些 Bootloader， 如 GRUB， 在 加 载 内 
核 期 间 就 已 经 将 CPU 切换 到 保护 模式 了 ， 寻 址 衬 间 的 限制 早已 不 是 问 


题 。 而 且 ， 如 今 软盘 基本 已 经 被 其 他 介质 蔡 代 ， 容 量 已 不 是 问题 。 


但 是 内 核 的 压缩 还 是 保留 了 下 来 ， 毕 竟 还 要 考虑 到 某 些 尺 寸 受 限 
的 情况 。 而 且 ， 现 代 CPU 解 压 的 速度 要 远大 于 IO 的 速度 ， 在 局 动 时 虽 
然 解压 要 耗费 一 点 时 间 ， 但 是 更 小 的 内 核 也 减少 了 加 载 时 间 。 


3.1.4 ”映像 的 格式 


不 知 读者 留意 到 没有 ， 无 论 是 setup.bin、vmlinux.bin， 还 是 
vmlinux.bin.gz， 命 名 中 都 包含 "bin" 的 字样 ， 这 是 开发 者 有 意 为 之 ， 还 是 机 
缘 巧 合 ? 显然 ， 这 个 bin 不 是 开发 人 员 随 意 杜撰 的 ， 而 是 binary 的 缩写 ， 表 示 
文件 格式 是 裸 二 进 制 (raw binary) 的 。 


读者 可 能 有 个 困惑 ， 在 Linux 操 作 系统 中 二 进 制 文件 的 格式 不 是 使 用 
ABI (Application Binary Interface) 规定 的 ELE 吗 ? 


没 错 ， 在 Linux 作 为 操作 系统 的 hosted environment 环 境 下 ， 二 进 制 文件 
使 用 ELF 格 式 ， 操 作 系统 也 提供 ELF 文 件 的 加 载 右 。 但 是 ， 操 作 系统 本 身 确 
是 工作 在 freestanding environment 环 境 下。 操作 系统 显然 不 能 强制 要 求 
Bootloader 也 提供 ELF 加 载 人 大。 而且， 操作 系统 映像 也 没有 必要 使 用 ELF 格 
式 来 组 织 ， 将 代码 和 数据 顺 次 存放 即 可 ， 即 所 谓 的 裸 二 进 制 格式 。 所 以 ， 
内 核 映 像 都 采用 裸 二 进 制 格式 进行 组 织 。 


但 是 ， 从 Linux 2.6.26 版 本 开始 ， 内 核 的 压缩 部 分 ， 即 有 效 载 傈 部 分 ， 
采用 了 ELF 格 式 。 至 于 为 什么 采用 ELF 格 式 ，Patch 的 提交 者 给 出 了 原因 : 


This allows other boot loaders such as the Xen domain builder the 
opportunity to extract the ELF file. 


我 们 知道 ， 在 解压 内 核 映 像 后 ， 将 会 跳 转 到 解压 映像 的 开头 执行 。 但 
征 ，ELE 文 件 的 开头 并 不 是 代码 段 的 开始 ， 而 是 ELF 文 件 头 ， 也 束 是 说 ， 并 


不 是 CPU 可 执行 的 机 器 指令 。 显 然 ， 当 内 核 映 像 不 是 裸 二 进 制 格式 时 ， 我 
们 需要 有 一 个 ELF 加 载 器 来 将 ELEF 格 式 的 内 核 映 像 转化 为 裸 二 进 制 格式 。 那 
么 谁 来 充当 这 个 ELF 加 载 器 呢 ? 


正 所 谓 “ 虹 螂 捕 蝉 ， 黄 汰 在 后 ”。 内 核 的 非 压 缩 部 分 调用 函数 decompress 
解压 内 核 后 ， 紧 接着 就 调用 了 函数 parse_elf 来 处 理 ELF 格 式 的 内 核 映像 ， 代 
码 如 下 : 


linux-3.7.4/arch/x86/boot/compressed/misc.c: 


asmlinkage void decompress kernel(...) 


decompress (input data, input len, ...); 
parse elf (output); 


} 


static void parse elf (void *output) 


{ 


for (i = 0; i < ehdr.e phnum; i++) { 
phdr = &phdrs [i]; 


switch (phdr->p type) { 
case PT_ LOAD: 
#ifdef CONFIG RELOCATABLE 
dest = output; 
dest += (phdr->p paddr - LOAD PHYSICAL ADDR); 


#else 
dest = (void *) (phdr-=>p paddr); 
#endif 
memcpy (dest, output + phdr->p offset, phdr->p filesz) ; 
break; 
default: /* Ignore other PT * */ break; 
} 
free (Phars) ; 


在 ELEF 文 件 中 ， 存 放 代 码 和 数据 的 段 的 类 型 是 PT_LOAD， 因 此 ， 仅 处 
理 这 个 类 型 的 段 即 可 。 在 函数 parse_elf 中 ， 对 于 类 型 是 PT_ LOAD 的 段 ， 其 


按照 Program Header Table 中 的 信息 ， 将 它们 移动 到 链接 时 指定 的 物理 地 址 
处 ， 即 p_paddr。 当 然 ， 如 果 内 核 是 可 重 定位 的 ， 还 要 考虑 内 核实 际 加 载 地 
址 与 编译 时 指定 的 加 载 地 址 的 差 值 。 


事实 上 ， 如 果 Bootloader 不 是 所 谓 的 "the Xen domain builder"， 我 们 完全 
没有 必要 保留 内 核 的 压缩 部 分 为 ELF 格 式 ， 并 上 略 去 启动 时 进行 
的 "parse_elf"。 具 体 方法 如 下 : 


(1) 将 压缩 部 分 链接 为 裸 二 进 制 格式 
将 传递 给 命令 objcopy 的 参数 追加 "-O binary"， 如 下 面 使 用 黑体 标识 的 
部 分 : 


linux-3.7.4/arch/x86/boot/compressed/Makefile: 
OBJCOPYFLAGS vmlinux.bin := -R .comment -S -0 binary 


$ (obj)/vmlinux.bin: vmlinux FORCE 
$ (call if changed,objcopy) 


(2) 注释 掉 parse_elf 


既然 内 核 压 缩 部 分 已 经 是 裸 二 进 制 格 式 的 了 ， 解 压 后 自然 不 再 需要 调 
用 函数 parse_elf 了 。 


linux-3.7.4/arch/x86/boot/compressed/misc.c: 


asmlinkage void decompress kernel(...) 


{ 


decompress (input data, input len, ...); 
/* parse elf(output); */ 


3.2 内核 映像 的 构建 过 程 


3.2.1 kbuild 简 介 


虽然 内 核 有 自己 的 构建 系统 kbuild， 但 是 kbuild 并 不 是 什么 新 的 东西 。 
我 们 可 以 把 kbuild 看 作 利用 GNU Make 组 织 的 一 套 复 杂 的 构建 系统 ， 虽 然 
kbuild 也 在 Make 基 础 上 作 了 适当 的 扩展 ， 但 是 因为 内 核 的 复杂 性 ， 所 以 
kbuild 要 比 一 般 项 目的 Makefile 的 组 织 要 复杂 得 多 。 虽 然 kbuild 很 复杂 ， 但 也 
是 有 章 可 循 的 ， 下 面 两 点 是 理解 kbuild 的 关键 。 


1.Makefile 的 包含 


Makefile 的 包含 是 很 多 复业 的 项 目 中 常用 的 方法 之 一 。 通 第 的 做 法 是 将 
共同 使 用 的 变量 或 规则 定义 在 一 个 文件 中 ， 在 需要 使 用 的 Makefile 中 使 用 关 
键 字 "include" 来 包含 这 个 文件 。kbuild 中 多 处 使 用 了 包含 的 方式 ， 其 中 关键 
的 两 处 我 们 需要 特别 指出 。 


(1) 顶层 Makefile 包 含 平台 相关 的 Makefile 


为 了 Linux 能 够 方便 地 支持 多 平台 ，kbuild 必 须 方便 添加 对 新 平台 的 支 
持 ， 同 时 上 层 的 Makefile 不 需要 做 大 的 改动 ， 甚 至 不 需要 改动 。 所 以 ， 
kbuild 将 与 平台 无 关 的 变量 、 规 则 等 放 到 了 顶层 的 Makefile 中 ， 平 台 相关 的 
部 分 定义 在 各 个 平台 的 “顶层 "Makefile 中 。 所 谓 各 个 平台 的 “项 


层 ”Makefile， 即 arch/$(SRCARCH) 目 杂 下 的 Makefile。 在 顶层 的 Makefile 中 
包含 平台 的 “顶层 ”Makefile， 脚 本 如 下 所 示 : 


linux-3.7.4/Makefile.: 


include s$(srctree)/arch/s (SRCARCH) /Makefile 


其 中 变量 SRCARCH 的 值 就 古 平台 相关 部 分 所 在 的 日 隶 ， 对 于 IA32 架 
构 ，SRCARCH 的 值 为 x86。 顶 层 Makefile 包 含 了 平台 的 “顶层 ”Makefile 后 ， 
才 组 成 了 真正 的 Makefile。 这 也 是 为 什么 我 们 在 顶层 目录 执行 "make 
bzImage" 这 样 的 命令 时 ， 可 以 编译 内 核 映像 ， 却 在 顶层 目录 下 的 Makefile 中 
找 不 到 目标 bzImage 的 原因 ， 因 为 其 在 平台 的 “顶层 ”Makefile 中 。 


(2) Makefile.build 包 含 各 个 子 目 录 下 的 Makefile 


为 了 方便 Linux 开 发 者 能 够 编写 Makefile，kbuild 考 虑 得 不 可 谓 不 周到 ， 
在 牺牲 自己 的 同时 (kbuild 的 实现 非常 烦琐 ， 确 实 让 Linux 的 开发 者 们 享 
受 了 便捷 。 比 如 ，kbuild 将 所 有 与 编译 过 程 相 关 的 公共 的 规则 和 变量 都 提取 
到 scripts 目 录 下 的 Makefile.build 中 ， 而 具体 的 子 目录 下 的 Makefile 文 件 则 可 
以 写 得 非常 简单 和 直接 。 


kbuild 定 义 了 若干 变量 ， 如 obj-y、obj-m 等 ， 用 于 记录 参与 编译 过 程 的 
文件 。 这 些 变量 就 像 钩子 或 者 回调 函数 ， 各 个 子 目 录 Makefile 只 需 为 其 赋 
值 ， 设 置 参与 编译 的 文件 即 可 ， 其 他 事情 都 由 Makefile.build 处 理 。 甚 至 最 
人 简单 的 Makefile 可 以 简单 到 只 有 一 行 语句 |: 


1inux-3.7.4/fs/notify/adnotify/Makefile : 


Obj-$ (CONFIG DNOTIFY) + TO 上 


在 编译 时 ，Makefile.build 会 指导 make 将 要 编译 的 子 目 录 下 的 Makefile 文 
件 包 含 到 Makefile.include 中 动态 地 组 成 完整 的 Makefile 文 件 ， 脚 本 如 下 : 


linux-3.7.4/scripts/Makefile.build: 
kbuild-dir := $ (if $ (filter /%,s$(src)),s$ (src),s$ (srctree)/$ (src)) 
kbuild-file := $(if $(wildcard $ (kbuild-dir) /Kbuild), 


$ (kbuild-dir) /Kbuild,$ (kbuild-dir) /Makefile) 
include $ (kbuild-file) 


理论 上 ， 要 包含 Makefile 文 件 ， 一 条 include 命 令 就 够 了 ， 为 什么 这 里 实 
现 得 如 此 复杂 ? 


一 是 因为 src 的 值 是 相对 于 顶层 目录 的 ， 所 以 在 顶层 目录 执行 make 没 有 
任何 问题 。 但 是 如 果 make 不 是 在 顶层 目录 执行 的 ， 那 么 就 需要 使 用 绝对 路 
径 来 定位 编译 的 子 目录 了 。 这 就 是 为 什么 既然 有 了 src， 还 要 定义 变量 
kbuild-dir。src 是 kbuild 中 定义 的 一 个 变量 ， 始 终 指向 需要 构建 的 目录 ， 
kbuild-dir 则 是 加 上 了 绝对 路 径 的 src。make 使 用 内 骸 范 数 filter 来 判断 编译 所 
在 的 目录 的 路 径 是 否 是 以 绝对 路 径 表 示 ， 即 以 “%* 开 涉 ， 如 果 不 是 ， 则 冠 以 
$(srctree)。srctree 记 录 内 核 顶层 目录 的 绝对 路 径 。 以 笔者 的 环境 为 例 ， 
srctree 的 值 是 /vita/build/linux-3.7.4。 在 一 般 情况 下 ， 构 建 都 发 生 在 顶层 目录 
下 ， 在 子 目 录 下 构建 是 为 内 核 开 发 人 员 提 供 的 特性 。 


二 是 因为 子 目 录 下 的 "Makefile" 文 件 毕竟 不 是 一 个 真正 意义 上 的 
Makefile， 所 以 kbuild 的 设计 者 的 初衷 是 硕 望 使 用 Kbuild 这 个 名 字 。 所 以 ， 


我 们 看 到 ， 在 确定 kbuild-file 时 ， 使 用 make 的 内 航 画 数 wildcard 首 移 党 试 匹配 
子 目 录 下 是 否 存 在 Kbuild 这 个 文件 。 如 果 有 则 优先 使 用 Kbuild， 否 则 使 用 
Makefile。 但 是 事实 上 ， 在 内 核 目 录 的 绝 大 部 分 子 目录 下， 人们 还 是 更 习惯 
使 用 Makefile 这 个 名 字 。 


2. 使 用 指定 Makefile 的 方式 进行 递归 


通常 ， 很 多 使 用 make 进 行 构建 的 项 目 ， 当 存在 多 级 目 孙 时 ， 使 用 递归 
方式 构建 ， 例 如 ; 


cd subdir && make 


也 殊 是 说 ， 在 子 目 录 下 构建 时 ， 首 先 要 切换 当前 工作 目录 到 子 目 录 ， 
然后 再 局 动 一 个 make 进 程 解释 执行 当前 目录 下 的 Makefile。 在 编译 一 些 规 模 
稍 大 一 点 的 软件 时 ， 我 们 经 常 看 到 make 不 断 通 过 cd 命令 切换 目 孙 ， 原 因 驶 
在 于 此 。 


但 是 ，kbuid 并 没有 采用 切换 目录 的 方式 。 在 kbuild 中 ，make 的 当前 工 
作 目 录 永 远 是 顶层 目录 ， 当 编译 子 目录 时 ，kbuild 通 过 命令 行 选项 -f 将 子 目 
录 的 Makefile 传 递 给 make， 从 而 达到 编译 子 目录 的 目的 。kbuild 使 用 的 典型 
方式 如 平 : 


$ (MAKE) S$(bulld)=<Subdalr> [target] 


其 中 MAKE 是 make 的 内 部 变量 ， 读 者 把 它 理解 为 nake 即 可 。 变 量 build 


在 Makefile.build 中 定义 : 


linux-3.7.4/scripts/Kbuild.include: 


# Shorthand for $(Q)S$(MAKE) -f scripts/Makefile.build obj= 


# Usage: 

# $(Q)S$ (MAKE) $ (build)=dir 

build := -f $(if $(KBUILD SRC),$ (srctree)/)scripts/Makefile.build 
ob] 


只 有 当 在 子 目录 进行 make 时 ， 变 量 KBUILD_SRC 才 会 被 设置 为 子 目 
录 ， 和 否则 ， 在 顶层 目录 进行 make 时 ， 该 变量 值 为 空 ， 所 以 make 的 内 藤 函 数 
if 的 返回 值 为 else 部 分 。 但 是 因为 f 函 数 的 else 部 分 为 空 ， 所 以 该 函数 返回 值 
为 空 。 正 如 注释 中 所 说 ， 变 量 build 相 当 于 下 面 这 段 脚本 的 简写 : 


-上 scripts/Makefile.build obj= 


我 们 进一步 把 上 面 的 make 命 令 展 开 : 
make -f scripts/Makefile.build obj=<subdir> [target] 
也 就 说 ， 通 过 命令 行 参 数 -f， 指 定 Makefile 为 scripts 目 好 下 的 
Makefile.build。 而 当 make 解 释 执行 Makefile.build 时 ， 再 将 子 目 录 中 的 


Makefile 包 含 到 Makefile.include 中 来 ， 动 态 地 组 成 子 目 孙 的 真正 的 


Makefile。 


l 


既然 通过 指定 Makefile 的 方式 编译 多 级 目 示 ， 而 make 又 始终 工作 在 顶层 
目 隶 下， 那么 必然 要 在 顶层 工作 目录 中 跟 踩 编译 所 在 的 子 目录 。 为 此 ， 


kbuild 定 义 了 两 个 变量 : src 和 obj。 其 中 ，src 始 终 指向 需要 构建 的 目录 ; obj 
指向 构建 的 目标 存放 的 目录 。 并 约定 ， 在 引用 源码 树 中 业已 存在 的 对 象 时 
使 用 变量 src， 引 用 编译 时 动态 生成 的 对 象 使 用 变量 obj。kbuild 在 脚本 中 小 
心地 维护 着 这 两 个 变量 的 值 。 实 际 上 ， 因 为 构建 的 目标 存放 的 目录 与 源 文 
件 经 常 在 同一 个 目录 下 ， 所 以 大 部 分 情况 下 这 两 个 变量 均 指 向 同一 个 目 
录 。 


理解 了 kbuild 中 这 两 个 变量 的 意义 后 ， 读 者 一 定 看 明白 了 人 上述 make 命 令 
中 参数 "obj= <subdir> "的 意义 ， 就 是 设置 变量 obj 的 值 ， 记 录 编 译 所 在 的 子 
目录 。 而 在 Makefile.build 的 一 开头， 变量 src 的 值 也 被 设置 为 $(obj)。 


linux-3.7.4/scripts/Kbuild,.include: 


SE 55 S(OBI) 
PHONY := build 
build: 


下 面 ， 我 们 惑 结合 构建 ITA32 织 构 下 的 内 核 映 像 bzImage， 探 讨 内 核 映 像 
的 具体 构建 过 程 。 


3.2.2 ”构建 过 程 概述 


在 编译 内 核 时 ， 通 常 我 们 只 需要 执行 "make bzImage"， 或 者 make 后 面 不 
接任 何 目标 。 在 没有 搂 目 标 时 ， 构 建 的 内 核 映 像 也 是 bzImage。 读 者 目 然 会 
问 : 我 们 并 没有 指定 构建 vmlinux、vmlinux.bin 和 setup.bin， 最 后 的 bzImage 
是 怎么 来 的 呢 ? 


虽然 我 们 没有 显示 指定 这 几 部 分 的 构建 ， 但 是 读者 想必 已 经 猜 出 来 
了 ， 这 是 Makefile 的 依赖 的 魔法 。 下 面 是 构建 bzImage 的 规则 ， 我 们 暂且 不 
讨论 它 的 由 来 ， 先 把 焦点 放 在 bzImage 的 依赖 天 系 上 : 


linux-3.7.4/arch/x86/boot/Makefile: 


$ (obj)/bzImage: $ (obj)/setup.bin $ (obj)/vmlinux.bin \ 
$ (obj)/tools/build FORCE 


根据 构建 规则 可 见 ，bzImage 依 赖 于 setup.bin 和 vmlinux.bin， 所 以 在 构 
建 bzImage 前 ，make 将 自动 完 去 构建 它们 ， 以 此 类 推 ，vmlinux 的 构建 也 是 
同样 的 道理 。 因 此 ， 组 成 内 核 映像 的 各 个 部 分 的 构建 顺序 如 下 : 


1) 构建 有 效 载 休 vmlinux， 并 将 其 压缩 为 vmlinux.bin.gz; 


2) 构建 二 级 推进 系统 ， 并 将 二 级 推进 系统 装配 到 有 效 载 入 上 ， 组 成 


vmlinux.bin: 


3) 构建 一 级 推进 系统 ， 即 构建 setup.bin; 


4) 将 setup.bin 和 vmlinux.bin 组 合 为 bzImage 。 


接 下 来 我 们 就 依 次 讨论 各 个 部 分 的 构建 过 程 。 


3.2.3 ”vmlinux 的 构建 过 程 


所 有 的 体系 结构 都 需要 构建 vmlinux， 所 以 vmlinux 的 构建 规则 在 顶层 的 
Makefile 中 。 


linux-3.7.4/Makefile: 


cmd link-vmlinux = $(CONFIG SHELL) $< $(LD) $ (LDFLAGS) \ 
$ (LDFLAGS vmlinux) 
vmlinux: scripts/link-vmlinux.sh $ (vmlinux-deps) 


FORCE 
+$ (call if changed,1ink-vmlinux) 


注意 ， 构 建 vmlinux 的 命令 使 用 了 make 的 内 置 画 数 call。 这 是 一 个 比较 
特殊 的 内 置 画 数 ，make 使 用 它 来 引用 用 户 自 己 定义 的 带 有 参数 的 函数 。 


放 changed 是 kbuild 定 义 的 一 个 函数 ， 这 里 通过 call 引 用 这 个 函数 ， 传 递 的 实 
参 


参 是 link-vmlinux。 男 数 放 changed 的 定义 如 下 : 


VS 


linux-3.7.4/scripts/Kbuild.include.: 


if changed = $(if $(strip $(any-prereq) 


$ (arg-check)), \ 
@set -e; NS 
$(echo-cmd) $ (cmd $(1)); \ 
echo ‘cmd $s@ := $ (make-cmd)’ 


> $(dot-target) .cmd) 


在 if_changed 中 ，any-prereq 检 查 是 否 有 依赖 比 目 标 新 ， 或 者 依赖 还 没有 
创建 ; arg-check 检 查 编译 目标 的 命令 相对 上 次 是 否 发 生变 化 。 如 果 两 者 中 
只 要 有 一 个 发 生 改 变 ， 就 执行 f 函 数 的 if 块 。 注 意 if 块 中 的 使 用 黑体 标识 的 部 


A 


分 ， 其 中 “1” 代 表 的 就 是 传 给 if_changed 的 第 一 个 实 参 。 由 此 可 见 ， 


让 changed 核 心 功能 就 是 当 目 标的 依赖 或 者 编译 命令 发 生变 化 时 ， 执 行 表达 
式 "cmd_4(1)" 展 开 后 的 值 。 


这 里 ， 传 给 if_changed 的 第 一 个 实 参 是 link-vmlinux， 因 此 ，cmd_$(1) 展 
开 后 为 cmd_link-vmlinux。 注 意 cmd_link-vmlinux 中 的 第 二 项 “$<”， 这 是 
make 的 自动 变量 ， 翻 译 自 "Automatic Variable"， 意 指 变量 名 相同 ， 但 是 
make 根 据 具 体 上 下 文 ， 将 其 自动 替换 为 合适 的 值 。 这 里 ，make 会 将 这 个 目 
动 变量 替换 为 构建 vmlinux 中 的 规则 中 的 第 一 个 依赖 ， 即 shell 脚 本 文件 
scripts/link-vmlinux.sh， 该 脚本 文件 中 负责 vmlinux 链 接 的 脚本 如 下 : 


linux-3.7.4/scripts/link-vmlinux.sh: 


vmlinux link() 


{ 


local lds="${objtree}/${KBUILD LDS}" 


i£ [. "SSRCARCHY" ls Mm ]$ then 
${LD} ${LDFLAGS} ${LDFLAGS vmlinux} -o ${2} \ 
-T ${lds} ${KBUILD VMLINUX INIT} \ 
--start-group ${KBUILD VMLINUX MAIN} --end-group ${1} 
else 


fi 


} 


vmlinux link "${kallsymso}" vmlinux 


根据 函数 vmlinux_link 的 实现 ， 如 果 平 台 不 是 "um"， 那 么 就 调用 链接 器 
将 变量 KBUILD_VMLINUX_INIT、KBUILD_VMLINUX_MAIN 中 记录 的 目 
标 文 件 链接 为 vmlinux。 我 们 看 看 这 两 个 变量 的 定义 : 


linux-3.7.4/Makefile : 


# Externally visible symbols (used by link-vmlinux.sh) 

export KBUILD VMLINUX INIT $ (head-y) $ (init-y) 

export KBUILD VMLINUX MAIN $ {core-y) $(libs-y) $ (drivers-y)\ 
$ (net-y) 


| 


我 们 以 core-y 为 例 来 分 析 变 量 KBUILD_VMLINUX_MAIN 的 值 。 


1inux-3.7.4/Makefile : 


Core-y v= VBE 
Core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ 
core-y := $ (patsubst %/, %/built-in.o, $ (core-y)) 


patsubst 是 make 的 内 置 函 数 ， 功 能 是 在 输入 的 文本 中 查找 与 模式 匹配 的 
字符 串 ， 然 后 使 用 特定 字符 串 进 行 替换 。 上 有 具体 到 这 里 ， 其 目的 就 是 在 变量 
core-y 的 值 中 将 字符 串 “/” 替 换 为 "built-in.o"。 经 过 函数 patsubst 替 换 后 ， 最 后 
变量 core-y 的 值 如 下 : 


Core-y := User/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o \ 
ipc/built-in.o security/built-in.o crypto/built-in.o \ 
block/built-in.o 


除了 各 个 子 目 录 下 的 built-in.o， 有 些 子 目录 (如 1lib) 下 还 会 编译 lib.a 。 
总 之 ，vmlinux 束 是 由 这 些 有 目录 下 的 built-in.o、1ib.a 等 链接 而 成 的 。 


那么 这 些 子 目 录 下 面 的 目标 文件 built-in.o 或 者 lib.a 是 在 什么 时 机 构建 的 
呢 ? 我 们 来 回顾 一 下 vmlinux 的 构建 规则 ; 


linux-3.7.4/Makefile: 


vmlinux: scripts/link-vmlinux.sh $ (vmlinux-deps) FORCE 


我 们 看 到 ， 除 了 依赖 scripts/link-vmlinux.sh，vmlinux 的 另外 一 个 依赖 是 
vmlinux-deps， 其 构建 规则 也 在 顶层 Makefile 中 定义 : 


1inux-3.7.4/Makefile : 
vmlinux-dirs se (patauibpet S/S (Lter SH/e SLinit=y) 
$s (init-m) $ (core-y) $(core-m) $ (drivers-y) $(drivers-m) \ 


$s (net-y) $ (net-m) $ (libs-y) $ (libs-m))) 


vmlinux-deps := $ (KBUILD LDS) $ (KBUILD VMLINUX INIT) 
$ (KBUILD VMLINUX MAIN) 


$s(sort $(vmlinux-deps)): $(vmlinux-dirs) ， 


$ (vmlinux-dirs): prepare scripts 
$ (Q) $ (MAKE) $ (build)=$@ 


我 们 首先 看 看 变量 vmlinux-deps， 显 然 ， 其 记录 的 就 是 我 们 前 面 讨论 的 
最 终 链接 为 vmlinux 的 内 核子 目录 下 的 目标 文件 的 名 字 ， 如 built-in.o 等 。 也 
就 说 ，vmlinux 的 构建 规则 表达 得 很 清楚 ， 要 最 后 链接 vmlinux， 首 先 需 要 构 
建 这 些 目 标 文件 。 但 是 注意 目标 vmlinux-deps 的 构建 规则 ， 其 “规则 体 * 是 空 
的 ， 也 束 是 说 这 个 构建 规则 下 没有 任何 命令 可 执行 ,但 是 可 以 看 到 这 些 目 
标 文 件 依赖 于 另外 一 个 目标 vmlinux-dirs， 我 们 继续 跟踪 目标 vmlinux-dirs 的 
构建 。 


我 们 来 关注 一 下 变量 vmlinux-dirs 的 值 。 注 意 该 变量 的 赋值 脚本 ， 其 中 
函数 filter 也 十 make 的 内 置 画 数 ， 其 功能 钙 过 滤 挥 输入 文本 中 不 以 “” 结 尾 的 
字符 叮 。 前 面 我 们 看 到 ， 输 入 到 fllter 的 这 些 变 量 ， 比 如 core-y， 其 中 所 有 的 
子 目录 都 以 “结尾 ， 因 此 ， 这 里 filter 的 目的 是 过 滤 掉 这 些 变量 中 的 非 目 
孙 。patsubst 这 个 make 的 内 置 函 数 我 们 刚刚 讨论 过 ， 显 然 是 将 过 滤 出 来 的 于 
目 孙 后 面 的 字符 “/" 去 掉 。 因 此 ， 正 如 其 名 字 所 揭示 的 ， 变 量 vmlinux-dirs 的 
值 是 多 个 目录 ， 所 以 构建 vmlinux-dirs 的 规则 也 是 一 个 多 目标 规则 ， 等 价 
本 


init: prepare scripts 
$(Q)S$(MAKE) $ (build)=$@ 

kernel: prepare scripts 
$(Q)S(MAKE) $ (build)=$@ 


规则 中 的 命令 展开 后 为 : 
make -f script/Makefile.build obj=$@ 


其 中 “$@” 是 make 的 自动 变量 ， 表 示 规 则 的 目标 ， 所 以 这 里 会 被 make 自 
动 替换 为 构建 的 子 目录 ， 如 init、kermel 等 ， 即 相当 于 逐个 编译 这 些 子 目录 ， 
使 用 的 Makefile 是 Makefile.build。 如 3.2.1 节 讨论 的 那样 ，Makefile.build 将 包 
合 构 建 目录 中 的 Makefile 或 Kbuild， 最 终 形成 完整 地 Makefile。make 命 令 中 
没有 显 式 指定 构建 目标 ， 因 此 ， 将 构建 Makefile.build 中 默认 的 目标 。 
Makefile.build 中 的 默认 目标 是 build， 脚 本 如 下 所 示 : 


linux-3.7.4/scripts/Makefile.build: 


BLE SE SOB 
PHONY := build 
__build: 


__ build: $(if $(KBUILD BUILTIN),$ (builtin-target) \ 
$ (lib-target) $ (extra-y)) \ 
$ (if $(KBUILD MODULES),$ (obj-m) $ (modorder-target)) \ 
$ (subdir-ym) $ (always) 


目标 _build 袖 兰 了 内 核 映 像 和 模块 ， 这 里 我 们 只 关注 内 核 映 像 的 构 
建 ， 不 关注 模块 的 构建 。 对 于 编译 内 核 映 像 来 说 ， 目 标 _build 依 赖 builtin- 


target、1lib-target、extra-y、subdir-ym 和 always。 我 们 先 来 看 builtin-target 和 


lib-target: 


linux-3.7.4/scripts/Makefile.build: 


ifneq ($(strip $(lib-y) $(libp-m) $(lib-n) $(1ib-));) 
lib-target := $ (obj)/lib.a 
endif 


ifneq ($(strip $(obj-y) $ (obj-m) $ (obj-n) $ (obj-) $ (subdir-m) 和 
$ (lib-target)),) 
builtin-target := $ (obj)/built-in.o 


endif 


根据 上 述 脚本 片断 可 见 ，builtin-target 代 表 的 就 是 子 目 录 下 的 built- 
in.o，lib-target 代 表 的 就 是 子 目 录 下 的 lib.a。 对 于 构建 的 子 目 录 ， 如 果 变 量 
obj-y 等 值 非 宇 ， 那 么 束 构 建 built-in.o。 如 果 变 量 lib-y 等 的 值 非 宝 ， 那 么 就 构 
建 lib.a。 我 们 来 看 看 built-in.o 和 lib.a 的 构建 : 


linux-3.7.4/scripts/Makefile.build: 

emd linko. age. = 届时 二 $tetrip (obj-y})):\ 
$(LD) $ (ld flags) -r -o $@ $(filter $(obj-y), $“°) \ 
$s (cmd secanalysis),\ 


rm -f $@; $(AR) rcs$ (KBUILD ARFLAGS) $@) 


$s (builtin-target): $(obj-y) FORCE 
$(call if changed; link o target) 


cmd link 1 target = rm -f $@; $(AR) rcs$ (KBUILD ARFLAGS) $@ $ (lib-y) 


$ (lib-target): $(lib-y) FORCE 
$(call if changed,link 1 target) 


前 面 已 经 讨论 过 函数 计 changed， 如 果 理 解 了 这 个 函数 ， 残 很 容易 理解 
built-in.o 和 1lib.a 的 构建 过 程 了 ， 对 于 built-in.o， 就 是 调用 链接 右 将 变量 obj-y 


中 记录 的 各 个 目标 文件 链接 为 builtrin.o。 对 于 lib-target， 束 是 调用 创建 静态 
库 的 程序 AR 将 变量 lib-y 中 的 各 个 目标 文件 链接 为 lib.a。 


编译 内 核 时 需要 一 些 临 时 工具 ， 比 如 我 们 前 面 用 到 的 mkpiggy 、build 
等 ， 这 些 是 一 定 需要 编译 的 ， 因 为 构建 内 核 时 会 用 到 。 因 此 ，kbuild 中 定义 
了 一 个 变量 always， 其 中 记录 的 驶 是 必须 要 编译 的 构建 目标 。 


另外 ， 可 能 有 多 层 目录 航 套 的 情况 ， 因 此 _build 依 赖 列 表 中 有 这 人 么 一 
项 :subdir-ym。 目标 subdir-ym 的 规则 如 下 : 


linux-3.7.4/scripts/Makefile .build.: 


$ (subdir-ym): 
$(Q)$ (MAKE) $ (build)=$@ 


上 面 的 代码 看 上 去 是 不 是 很 熟悉 ? 没 错 ， 它 和 前 面 处 理 vmlinux-dirs 的 
规则 完全 相同 ， 显 然 ， 这 是 在 处 理 目录 中 还 有 子 目 好 的 情况 。 


至 此 ， 链 接 vmlinux 的 目标 文件 经 构建 完成 。 回 顾 一 下 vmlinux 的 构建 过 
程 ，kbuild 将 依次 构建 Makefile 中 指定 的 子 目 隶 ， 生 成 builtin.o、1ib.a 等 目标 
文件 ， 然 后 调用 链接 器 将 这 些 目标 文件 链接 为 vmlinux， 并 保存 在 顶层 目录 
下 。 


3.2.4_vmlinux.bin 的 构建 过 程 


根据 图 3-1 可 知 ，kbuild 将 有 效 载 荷 与 内 核 的 非 压缩 部 分 装配 为 
vmlinux.bin。 我 们 前 面 已 经 看 到 了 有 效 载 荷 wmlinux 的 构建 过 程 ， 这 一 节 我 
们 讨论 二 级 推进 系统 的 构建 ， 并 看 看 二 级 推进 系统 是 如 何 与 有 效 载荷 进行 
装配 的 。 构 建 vmlinux.bin 的 规则 在 arch/x86/boot 目 录 下 的 Makefile 中 


1inux-3.7.4/arch/x86/boot/Makefile : 
OBJCOPYFLAGS vmlinux.bin := -0O binary -R .note -R .comment -S 


$ (obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE 
$ (call if changed,objcopy) 


根据 前 面 对 kbuild 目 定义 函数 if_changed 的 讨论 可 知 ， 这 里 将 执行 命令 
cmd_objcopy。cmd_objcopy 的 定义 如 下 : 


1inux-3.7.4/scripts/Makefile.1ib : 


cmd objcopy = $ (OBJCOPY) $ (OBJCOPYFLAGS) $ (OBJCOPYFLAGS $ (@F)) \ 
$< S$@ 


其 中 OBJCOPY 束 是 二 进 制 工 具 objcopy， 当 然 ， 因 为 我 们 使 用 的 是 交叉 
工具 链 ， 所 以 objcopy 是 i686-none-linux-gnu-objcopy， 前 面 构建 工具 链 时 构 
建 组 件 Binutils 时 已 经 构建 : 


linux-3.7.4/Makefile: 


OBJCOPY = $(CROSS COMPILE)objcopy 


这 里 使 用 这 个 工具 的 目的 是 将 ELEF 格 式 的 文件 转化 为 裸 二 进 制 格式 。 


cmd_objcopy 中 的 “$<”、“$@”、“$(@F)” 都 是 make 的 目 动 变 
量 ,“$< ”表示 规则 的 依赖 列表 中 的 第 一 个 依赖 ， 这 里 是 
arch/x86/boot/compressed/vmlinux; “$@” 表 示 规 则 的 目标 ， 这 里 是 
arch/x86/boot/vmlinux.bin; “$(@F)”* 表 示 构 建 目标 去 除 目录 后 的 文件 名 ， 这 
里 是 vmlinux.bin， 因 此 变量 OBJCOPYFLAGS_$(@F) 展 开 为 


OBJCOPYFLAGS_vmlinux.bin。 和 替换 各 个 变量 后 ，cmd_objcopy 最 后 展开 大 
致 为 : 
cmd objcopy = i686-none-linux-gnu-objcopy -0 binary -R .note \ 


-R .comment -S arch/x86/boot/compressed/vmlinux \ 
arch/x86/boot/vmlinux.bin 


上 述 代码 的 意义 已 经 显而易见 了 : arch/x86/boot 目 录 下 的 vmlinux.bin 是 
由 arch/x86/boot/compressed 目 录 下 的 vmlinux 通 过 工具 i686-none-linux-gnu- 
objcopy 复 制 而 来 。 


为 了 指导 加 载 器 加 载 ELF 文 件 ，ELF 文 件 中 附加 了 很 多 信息 ， 如 ELF 文 
件 头 、Program Header Table、 符 号 表 、 重 定位 表 等 。 但 是 这 些 对 内 核 是 没 
有 意义 的 ，Bootloader 加 载 内 核 时 不 需要 ELF 文 件 中 附加 的 这 些 信息 ， 变 量 
OBJCOPYFLAGS_vmlinux.bin 中 的 "-O binary" 指 定 objcopy 将 复制 后 内 核 转 换 
为 裸 二 进 制 格 式 ， 选 项 (如 ".note"、".comment") 则 表明 将 这 些 段 也 删除 。 
读者 可 能 会 问 ， 转 化 为 裸 二 进 制 格式 时 还 会 保留 如 ".note"、".comment" 等 段 
吗 ? 当然 了 ， 转 化 为 裸 二 进 制 格式 只 不 过 把 为 ELF 格 式 附加 的 东西 去 除 掉 


了 ， 比 如 ELF 的 头 、Section Header Table、Program Header Table 等 ， 但 是 并 
不 会 删除 保存 具体 内 容 的 段 。 


显然 ， 构 建 的 焦点 转换 为 arch/x86/booVcompressed 下 的 vmlinux， 其 构 
建 规则 如 下 : 


linux-3.7.4/arch/x86/boot/Makefile.: 


$ (obj)/compressed/vmlinux: FORCE 
$(Q)$ (MAKE) $ (build)=$ (obj)/compressed $@ 


构建 命令 展开 为 : 


make -f scripts/Makefile.build obj=arch/x86/boot/compressed 
arch/x86/boot/compressed/vmlinux 


Makefile.build 将 arch/x86/boot/compressed 目 录 下 的 Makefile 包 含 到 
Makefile.build 中 ， 生 成 完整 的 Makefile。 但 是 这 次 ，make 没 有 如 同 构建 各 个 
子 目 录 一 样 使 用 默认 的 构建 目标 ， 而 是 指定 了 构建 目标 为 
arch/x86/bootcompressed/vmlinux， 其 构建 规则 在 arch/x86/bootcompressed 目 
录 下 的 Makefile 中 定义 : 


linux-3.7.4/arch/x86/boot/compressed/Makefile: 


VMLINUX OBJS = $(obj)/vmlinux.lds $ (obj)/head $ (BITS).o0o \ 
S(ODJ]) /nie (GBI /SCEILnGG 和 DJ cenadLine sd. \ 
$ (obj)/early serial console.o $(0obj)/piggy.o 


$ (obj)/vmlinux: $(VMLINUX OBJS) FORCE 
$ (call if changed,14d) 


对 于 32 位 系统 ， 变 量 BITS 为 32。 由 上 述 Makefile 可 见 
arch/x86/boot/compressed 目 好 下 的 vmlinux 是 由 该 上 日 录 下 的 head_32.0、 
misc.0、 string.0、cmdline.0、early_serial_console.0 以 及 piggy.o 链 接 而 成 的 。 
其 中 vmlinux.lds 是 指导 链接 过 程 的 脚本 。 


在 一 份 刚 刚 解压 且 没 有 进行 任何 编译 动作 之 前 的 内 核 源码 中 ， 除 了 
piggy.0， 我 们 可 以 找到 上 述 依赖 列表 中 任何 一 个 目标 文件 的 源 文 件 ， 比 如 
head_32.o 对 应 源 文 件 head_32.S，misc.o 对 应 源 文件 misc.c 等 。 而 我 们 却 找 不 

到 piggy.0 对 应 的 源 文件 ， 比 如 piggy.c 或 piggy.S 亦 或 其 他 。 但 是 仔细 观察 ， 
我 们 会 发 现在 arch/x86/boot/compressed 目 隶 下 的 Makefile 中 有 一 个 创建 文件 
piggy.S 的 规则 : 


linux-3.7.4/arch/x86/boot/compressed/Makefile.: 
cmd mkpiggy = $(obj)/mkpiggy $< > $@ || ( rm -f $@ ; false ) 
$ (obj)/piggy.S: $(obj)/vmlinux.bin.$ (suffix-y) $ (obj)/mkpiggy \ 


FORCE 
$ (call if changed,mkpiggy) 


看 到 上 面 的 规则 ， 我 们 悦 然 大 悟 ， 原 来 piggy.o 是 由 piggy.S 汇 编 而 来 ， 
而 piggy.S 是 编译 内 核 时 动态 创建 的 ， 这 束 是 我 们 找 不 到 它 的 原因 。piggy.S 
的 第 一 个 依赖 vmlinux.bin.$(suffix-y) 中 的 suffix-y 表 示 内 核 压 缩 方式 对 应 的 后 


级 : 
linux-3.7.4/arch/x86/boot/compressed/Makefile.: 


suffix-$ (CONFIG KERNEL GZIP) := 9g2Z 
suffix-$ (CONFIG KERNEL BZIP2) "3 BZ2 


如 采 配 置 内 核 时 指定 采用 gzip 压 缩 方 式 ， 则 suffix-y 值 为 gz; 如 采 指 定 
bzip2 压 缩 方 式 ， 则 suffix-y 值 为 bz2; 等 等 。 在 本 书 中 ， 我 们 配置 的 内 核 使 用 
默认 的 压缩 方式 gzip， 因 此 ，suffix-y 的 值 为 gz。 那 么 vmlinux.bin.gz 是 什么 
呢 ? 我 们 看 下 面 的 脚本 : 


linux-3.7.4/arch/x86/boot/compressed/Makefile. 


vmlinux.bin.all-y := $ (obj)/vmlinux.bin 
vmlinux.bin.all-$ (CONFIG X86 NEED RELOCS) += \ 
$ (obj) /vmlinux.relocs 


$ (obj)/vmlinux.bin.gz: $ (vmlinux.bin.all-y) FORCE 
$ (call if changed,gzip) 


看 到 这 里 ， 相 信 读 者 已 经 不 需要 看 cmd_gzip 的 定义 了 。 根 据 变量 
vmlinux.bin.all-y 的 值 ，vmlinux.bin.all-y 中 包括 arch/x86/bootcompressed 目 录 
下 的 vmlinux.bin。 如 果 内 核 被 配置 为 可 重 定位 的 ， 那 么 vmlinux.bin.all-y 中 还 
包括 记录 重 定 位 信息 的 vmlinux.relocs。 也 就 是 说 ， 如 有 果 内 核 被 配置 可 重 害 
位 ， 则 vmlinux.bin.gz 是 由 vmlinux.bin 和 vmlinux.relocs 压 缩 而 来 的 ， 否 则 只 


是 vmlinux.bin 由 压缩 而 来 。 


那么 arch/x86/boot/compressed 目 录 下 的 vmlinux.bin 义 是 如 何 创 建 的 ? 看 
下 面 的 脚本 : 
linux-3.7.4/arch/arch/x86/boot/compressed/Makefile.: 
OBJCOPYFLAGS vmlinux.bin := -R .comment -5S 


$ (obj)/vmlinux.bin: vmlinux FORCE 
$ (call if changed,objcopy) 


我 们 再 次 看 到 了 熟悉 的 objcopy， 世 就是 说 ，arch/x86/boot/compressed 目 
杂 下 的 vmlinux.bin 苹 由 vmlinux 复 制 而 来 。 而 vmlinux 没 有 任何 修饰 前 级 ， 这 
说 明 其 束 是 最 顶层 日 录 下 的 有 效 载 集 。 但 是 在 这 里 我 们 也 看 到 ， 这 次 复制 
过 程 只 是 删除 了 ".comment" 段 ， 以 及 符号 表 和 重 定 位 表 (通过 参数 -S 指 
定 ) ， 而 有 效 载 答 vmlinux 的 格式 依然 是 ELF 格 式 的 ， 如 果 不 需 要 使 用 ELF 
格式 的 内 核 ， 这 里 追加 一 个 "-O binary" 即 可 。 


至 此 ， 我 们 明白 了 vmlinux.bin.gz 就 是 有 效 载荷 的 压缩 。 


接着 我 们 再 来 看 构建 目标 piggy.S 的 命令 。 进 行 变量 替换 后 ， 
cmd_mkpiggy 展 开 为 : 
cmd mkpiggy = arch/x86/boot/compressed/mkpiggy \ 


arch/x86/boot/compressed/vmlinux.bin.gz \ 
> arch/x86/boot/compressed/piggy.s 


其 中 mkpiggy 是 内 核 目 带 的 一 个 工具 程序 ， 源 码 如 下 : 


linux-3.7.4/arch/x86/boot/compressed/mkpiggy.c: 


int main(int ‘arge; char *argvl]) 


{ 


printf(".section \'".rodata..compressed\",\"a\",\ 
@progbits\n"); 


printf(" globl, z nput: Tenvn)s 


( 
BEintf( "zm TBut Len SG Sl1U\n™ TLenm)y 
printE ("slobl Zz Outpuat LenNn™), 
printf("z output len = $lu\n'", (unsigned long)olen); 
pilntE(vglobl Z ertract offaet\in)s 
Pliner (ns ‘extriackt Off6et E DxSLeN ps GEES)S 


peinte(" nepblin MSo\"Vi”, OO] 


mkpiggy 向 屏幕 打印 了 一 堆 文本 。 习 惯 上 ， 我 们 会 认为 标准 输出 残 是 屏 
幕 ， 但 是 回头 再 仔细 观察 一 下 cmd_mkpiggy 的 定义 ， 其 将 标准 输出 重 定向 到 
了 文件 piggyS， 所 以 这 里 printf 实 际 上 是 在 组 织 汇 编 语 句 ， 然 后 输出 到 
piggy.S 中 。 也 就 是 说 ，mkpiggy 就 是 在 “ 写 ” 一 个 汇编 程序 。 


根据 代码 可 见 ， 这 个 piggy.S 非 常 简单 ， 其 使 用 汇编 指令 incbin 将 压缩 的 
有 效 载 集 vmlinux.bin.gz 不 加 更 改 地 直接 包含 进来 。 除 了 包含 了 压缩 的 内 核 
映像 外 ，piggy.S 中 还 定义 了 解压 vmlinux.bin.gz 时 需要 的 各 种 信息 ， 包 括 压 
缩 映像 的 长 度 、 解 压 后 的 长 度 等 ， 在 解压 内 核 时 ， 解 压 代码 将 需要 这 些 信 
妃 。 下 面 是 mkpiggy 生 成 的 一 个 具体 的 piggy.S 示 例 : 


.Section ".rodata..compressed", "a'",@progbits 
“globl z input len 

z input len = 1721557 

.globl z output len 

z Output len = 3421472 

‘Slobl Zz ‘extract offset 

z extract offset = 0x1lb0000 

‘globl 2z extract offset negative 

z extract offset negative = -0x1b0000 

.globl input data, input data end 

input data: 

.incbin "arch/x86/boot/compressed/vmlinux.bin.gz" 
input data end: 


终于 结束 了 这 个 让 人 胶 汉 的 过 程 ， 让 我 们 来 回顾 一 下 vmlinux.bin 的 构建 
过 程 : 


1) kbuild 使 用 objcopy， 将 顶层 Makefile 构 建 好 的 内 核 映 像 vmlinux 复 制 
到 arch/x86/boot/compressed 目 孙 下 ， 删 除了 ".comment" 段 、 符 号 表 和 重 定 位 
表 ， 并 命名 为 vmlinux.bin; 


2) kbuild 压 缩 内 核 映像 vmlinux.bin， 笔 者 采用 默认 的 压缩 方式 gzip， 所 
以 压缩 后 的 内 核 映 像 为 vmlinux.bin.gz; 


3) kbuild 借 助 内 核 自 带 的 程序 mkpiggy 构 建 一 个 汇编 程序 piggy.S， 该 汇 
编程 序 就 是 vmlinux.bin.gz 加 上 一 些 解压 内 核 时 需要 的 信息 ; 


4) kbuild 将 head_32.0、misc.o 以 及 包含 压缩 映像 的 piggy.o 等 目标 文件 链 
接 为 vmlinux.bin， 保 存 到 arch/x86/boot 目 录 下 。 


可 见 ，vmlinux.bin 由 压缩 的 vmlinux 加 上 以 head_32.o 为 代表 的 一 小 部 分 
非 压缩 代码 组 成 。vmlinux 就 是 我 们 提 到 的 有 效 载 衙 ， 而 这 部 分 非 压缩 代码 
就 是 我 们 所 谓 的 二 级 推进 系统 。 


3.2.5 ”setup.bin 的 构建 过 程 


构建 setup.bin 的 规则 也 在 arch/x86/boot 目 录 下 的 Makefile 中 : 


linux-3.7.4/arch/x86/boot/Makefile: 
setup-y += a20.0 bioscall.o cmdline.o copy.o cpu.o cpucheck.o 
SETUP OBJS = $ (addprefix $ (obj)/,s$ (setup-y)) 
LDFLAGS setup.elf 过 到了 
$ (obj)/setup.elf: $(src)/setup.ld $(SETUP OBJS) FORCE 
$ (call if changed,14d) 
OBJCOPYFLAGS setup.bin := -0 binary 
$ (obj)/setup.bin: $ (obj)/setup.elf FORCE 
$ (call if changed,objcopy) 
根据 setup.bin 的 构建 命令 可 见 ，setup.bin 是 由 setup.efl 经 过 objcopy 复 制 
而 来 的 。 根 据 构 建 setup.elf 的 规则 可 见 ， 构 建 setup.elf 的 命令 为 cmd_1d4， 其 定 


义 如 下 : 
linux-3.7.4/scripts/Makefile.1ib: 


cmd ld = $(LD) $ (LDFLAGS) $ (ldflags-y) $ (LDFLAGS $ (@F)) \ 
$s (filter-out FORCE,$’) -o $@ 


这 里 LD 就 是 链接 器 i1686-none-linux-gnu-ld， 定 义 在 顶层 Makefile 中 : 


linux-3.7.4/Makefile: 


LD = $(CROSS COMPILE)1d 


链接 器 的 输出 就 是 规则 的 目标 《“$@”) ， 这 里 就 是 setup.elf。“$^" 也 是 
make 的 一 个 自动 变量 ， 表 示 规 则 的 全 部 依赖 ， 所 以 这 里 链接 器 的 输入 即 是 
规则 的 依赖 ， 但 是 使 用 make 的 内 置 画 数 旬 ter-out 过 滤 掉 了 依赖 中 的 伪 目 标 
FORCE， 因 此 输入 是 arch/x86/boot/setup.ld 和 $(SETUP_OBJS)。 其 中 ， 
setup.ld 是 传递 给 链接 器 的 链接 脚本 ; SETUP_OBJS 对 应 的 则 是 变量 setup-y 
中 记录 的 目标 文件 ， 只 不 过 使 用 make 的 内 置 画 数 addprefix 在 这 些 文件 前 面 
中 添加 了 一 个 前 级 ， 目 的 是 在 顶层 目录 中 能 找到 这 些 目标 文件 。 


这 里 我 们 看 到 了 kbuild 的 一 个 约定 ， 虽 然 都 在 arch/x86/boot 目 录 下 ， 但 
是 引用 原本 就 存在 的 文件 setup.ld 使 用 的 是 变量 src， 而 引用 动态 创建 的 
SETUP_OBJS 则 使 用 了 变量 obj。 


将 上 述 变量 替换 到 cmd_ld4，cmd _ ld 最 后 展开 为 : 


cmd 1d = i686-none-linux-gnu-ld -T arch/x86/boot/setup.1d \ 
arch/xe6/boot/a20.6 arceh/xe6 /boot/Dioacall,D senN 
-O arch/x86/boot/setup.elf 


也 就 说 ， 链 接 絮 依照 链接 脚本 setup.l1d， 将 arch/x86/boot 目 如 下 的 目标 文 
件 a20.o、bioscall.o 等 链接 为 setup.elf 。 


但 是 setup.elf 也 是 ELEF 格 式 的 ，ELEF 附 加 的 一 些 信息 对 内 核 是 没有 意义 
的 ， 所 以 kbuild 也 将 ELF 格 式 的 setup.elf 转 换 为 裸 二 进 制 格 式 的 setup.bin。 至 
此 ， 一 级 推进 系统 准备 完成 。 


3.2.6 ”bzImage 的 组 合 过 程 


一 级 推进 系统 和 包括 有 效 载 集 的 二 级 推进 系统 都 已 束 绪 ， 这 一 ,我 
们 残 来 讨论 一 级 推进 系统 和 二 级 推进 系统 的 组 合 。 组 合 的 规则 定义 在 平台 
的 “顶层 "Makefile 中 : 


1inux-3.7.4/arch/x86/Makefile : 
boot := arch/x86/boot 

KBUILD IMAGE := $ (boot) /bzImage 
ne vmlinux 


$(Q)$ (MAKE) $ (build)=$ (boot) $ (KBUILD IMAGE) 


在 将 各 个 变量 进行 奉 换 后 ， 构 建 bzImage 的 命令 展开 为 : 


make -f scripts/Makefile.build obj=arch/x86/boot 
arch/x86/boot/bzImage 
Makefile.build 将 包含 在 arch/x86/boot 目 录 下 的 Makefile 文 件 组 成 为 最 终 
的 Makefile。 构 建 目标 arch/x86/boot/bzImage 的 规则 在 arch/x86/boot 下 的 


Makefile 中 : 


linux-3.7.4/arch/x86/boot/Makefile: 


$ (obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin \ 
$ (obj)/tools/build FORCE 
$ (call if changed, image) 


我 们 来 看 看 构建 bzImage 的 命令 cmd_image， 其 在 arch/x86/boot/Makefile 
中 定义 : 


linux-3.7.4/arch/x86/boot/Makefile: 


cmd image = $ (obj)/tools/build $ (obj)/setup.bin \ 
$ (obj)/vmlinux.bin > $@ 


根据 cmd_image 的 定义 ， 表 面 上 就 是 执行 程序 build， 并 传递 给 程序 build 
两 个 参数 ， 分 别 是 arch/x86/boot 目 录 下 的 setup.bin 和 vmlinux.bin， 同 时 将 程 
序 build 的 标准 输出 stdout 重 定向 到 规则 的 目标 ($@) ， 即 bzImage。 那 么 程 
序 build 究 竟 做 了 什么 呢 ? 我 们 来 看 看 它 的 源码 : 


linux-3.7.4/arch/x86/boot/tools/build.c: 


1 /* This must be large enough to hold the entire setup */ 
2 u8 buf [SETUP SECT MAX*512]; 

4 int main(int argc, char ** argv) 

5 

6 wh 

yi void *kernel; 

8 Ws 

9 le SS fopenmtargyll)s Vem) 

10 i 

工 志 到 fread(buf; 1s Slzeof (buf), Tley); 

4 i 

3 fd = open(argv[2], O RDONLY); 

14 ra 

15 kernel = mmap (NULL, sz, PROT READ, MAP SHARED, fd, 0); 
16 a 

下 7 于 二 WE 

18 i 

19 if (fwrite{(kernel, 1, sz, Stdout) != 82) 

20 


1) argv[1] 对 应 的 是 setup.bin， 所 以 第 9 行 代码 就 是 将 文件 setup.bin 打 
开 ， 第 11 行 代码 是 将 其 内 容 读 到 数组 buf 中 。 由 第 1 行 的 注释 可 见 ， 数 组 buf 
就 是 用 来 存放 setup.bin 的 。 


2) argv[2] 对 应 的 是 vmlinux.bin， 所 以 第 13 行 代码 是 将 文件 vmlinux.bin 
打开 。 因 为 vmlinux.bin 尺 寸 较 大 ，build 并 没有 使 用 与 setup.bin 相 同 的 方式 读 
取 vmlinux.bin， 而 是 将 vmlinux.bin 映 冉 到 build 的 进程 空间 中 ， 变 量 kernel 指 
向 了 vmlinux.bin 映 里 的 基 址 ， 如 代码 第 15 行 所 示 。 也 就 是 说 ，build 通 过 内 
存 映 射 的 方式 读 取 文件 vmlinux.bin 。 


3) 第 17 行 代码 是 将 读 取 到 buf 中 的 setup.bin 写 入 到 标准 输出 
(stdout) 。 而 根据 cmd_image 的 定义 ，build 程 序 已 经 将 其 标准 输出 重 定向 
为 bzImage， 所 以 这 里 并 不 是 将 setup.bin 显 示 到 屏幕 上 ， 而 是 写 入 到 文件 
bzImage 中 。 


4) 同 理 第 19 行 代码 是 将 vmlinux.bin 写 入 到 文件 bzImage 中 。 


可 见 ， 程 序 build 就 是 将 setup.bin 和 vmlinux.bin 简 单 地 连接 为 bzImage 。 


3.2.7 内核 映 像 构建 过 程 总 结 


前 面 我 们 简要 讨论 了 内 核 映像 的 构建 ， 内 核 映像 的 构建 过 程 大体 上 可 
以 概括 为 “三 次 编译 链接 ， 一 次 组 合 "， 如 图 3-2 所 示 。 


Ns 5 一- 一 一 uncompressed 
; larch/x86/kernel/ [一 一 一 ee 、 
head_32.0 Ww | farch/x86/boot/ 


: | : / 
; piggy.S ;| compressed 
: arch/x86/kernel/ | y | Nead Sim 
init_task.o 1d objcopy arch/x86/boot gzip 
: 一 一 vmlinux 天 | compressed| — > as 
:| init/built-in.o vmlinux.bin vmlinux.bin.gz 一 oarch/x86/boot 8 
HC :| compressed/ 加 
| : 局 
; |kernel/built-in.o piggy.o 
oo 


: arch/x86/boot | | Im 
: a20.0 arch/x86/boot/| objcopy :|arch/x86/boot/ 
setupelf | setup.bin 


: farch/x86/boot/ , : 
: pe : objcopy larch/x86/boot/ 


arch/x86/boot/ : 忆 一 一 一 一 | compressed/ 
bzlmage arch/x86/boot/ : Jarch/x86/boot/ vmlinux 
tools/build ;| vmlinux.bin 


图 3-2 内 核 映 像 构建 过 程 


(1) 第 一 次 编译 链接 


kbuild 分 别 编 译 各 个 于 目录 下 的 目标 文件 ， 如 built-in.o、lib.a 《如 采 
有 ) 等 ， 然 后 将 他 们 链接 为 ELF 格 式 的 vmlinux， 并 存放 在 顶层 目录 中 。 
一 步 相 当 于 构建 有 效 载荷 。 


(2) 第 二 次 编译 链接 


kbuild 使 用 工具 objcopy， 将 顶层 目录 的 vmlinux 复 制 到 
arch/x86/boot/compressed 目 未 下 ， 去 掉 其 中 的 符号 信息 、 重 定位 信息 ， 删 除 
段 ".comment"， 并 命名 为 vmlinux.bin。 然 后 ，kbuild 将 其 压缩 为 
vmlinux.bin.gz (假设 内 核 采用 i i 式 ) ， 封 装 到 piggy.S 中 ， 
并 调用 汇编 右 将 其 编译 为 piggyo， 这 一 步 是 对 有 效 载 傈 进行 了 压缩 。 


同时 ，kbuild 也 调用 编译 堪 编 译 arch/x86/bootcompressed 目 了 永 下 的 
head_32.c、misc.c 等 作为 内 核 的 非 压缩 部 分 ， 这 一 步 相 当 于 构建 二 级 推进 系 


统 。 


然后 ，kbuild 调 用 链接 磊 将 压缩 的 有 效 载 集 和 二 级 推进 系统 链接 为 
vmlinux。 注 意 这 里 文件 名 虽然 也 是 vmlinux， 但 是 不 要 与 顶层 目录 下 的 
vmlinux 混 消 ，arch/x86/boot/compressed 目 录 下 的 vmlinux 是 二 级 推进 系统 和 
有 效 载 答 的 组 合 ， 与 顶层 目录 下 的 vmlinux 是 包含 的 关系 。 


最 后 ，kbuild 调 用 objcopy 将 arch/x86/boot/compressed 目 录 下 的 vmlinux 复 
制 到 arch/x86/boot 目 了 永 下 ， 同 时 将 其 转换 为 裸 二 进 制 格式 ， 并 命名 为 
vmlinux.bin， 为 在 arch/x86/boot 目 录 下 进行 的 最 后 的 组 装 做 好 准备 。 


(3) 第 三 次 编译 链接 


kbuild 将 arch/x86/boot 下 的 a20.0、bioscall.o 等 目标 文件 链接 为 setup.elf， 
使 用 objcopy 将 其 转换 为 裸 二 进 制 格式 ， 并 命名 为 setup.bin。 这 一 步 ， 相 当 于 
构建 一 级 推进 系统 。 


(4) 一 次 组 合 


最 后 ，kbuild 调 用 内 核 自 带 的 程序 build， 将 vmlinux.bin 和 setup.bin 合 并 
为 bzImage。 至 此 ， 航 天 属 的 一 级 推进 系统 和 包含 有 效 载 傈 的 二 级 推进 系统 


装配 完毕 。 


在 3.1 节 ， 我 们 曾 粗 略 讨论 了 内 核 映像 的 组 成 。 在 了 解 了 内 核 的 构建 过 
程 后 ， 让 我 们 近 距 离 的 再 观察 一 下 bzImage。 以 下 是 bzImage 的 链接 脚本 : 


linux-3.7.4/arch/x86/boot/compressed/vmlinux.1ds.s: 


SECTIONS 


{ 
"i 
.head.text : { 


head = 。; 


HEAD TEXT 
ehead = .，; 
} 
.rodata..compressed : { 
*(.rodata. .compressed) 
} 
EBxE: 过 代 


} 


.rodata : { 


-ata 名 A 


= ALIGN (L1 CACHE BYTES) ; 
Boa § 1 
bss = .; 


ebss = .; 
} 


#ifdef CONFIG X86 64 


#endif 
end = ,7 
} 


首先 来 看 链接 脚本 中 的 段 ".head.text"， 其 中 宏 HEAD_TEXT 的 定义 为 : 


linux-3.7.4/include/asm-generic/vmlinux.1ds.h: 


#define HEAD TEXT *(.head.text) 


而 结合 文件 head_32.5: 


linux-3.7.4/arch/x86/boot/compressed/head 32.3: 
.text 
#include <linux/init.h> 


__HEAD 
ENTRY (startup 32) 


ENDPROC (startup_ 32) 


text 
relocated: 
/* 
* Clear BSS (stack is currently empty) 
a 
xOrl] Seax, Seax 


以 及 宏 _HEAD 的 定义 : 


linux-3.7.4/include/linux/init.h: 


#define __ HEAD .Section "head, text"; "ax" 


可 见 ， 在 head_32.S 中 ， 画 数 startup_32 通 过 安 _HEAD 明 确 要 求 链接 器 
将 函数 startup_32 链 接 到 段 ".head.text"。 而 根据 bzImage 的 链接 脚本 ， 
段 ".head.text" 被 安排 在 了 内 核 映像 的 起 始 位 置 ， 也 就 是 说 ， 辑 数 startup_32 
被 链接 到 了 内 核 映像 的 开头 。 


接 下 来 的 段 ".rodata..compressed"， 想 必 读 者 一 定 猿 出 来 了 ， 这 里 束 是 放 
置 内 核 的 压缩 映像 部 分 。 根 据 piggy.5 的 内 容 即 可 见 这 一 点 : 


linux-3.7.4/arch/x86/boot/compressed/piggy.s: 
.Section ".rodata..compressed'",'"a'",@progbits 
iglobl Zz input len 

z input len = 1721556 


.incbin "arch/x86/boot/compressed/vmlinux.bin.gz" 
input data end: 


在 piggy.S 中 ， 明 确定 义 了 内 核 压 缩 部 分 所 在 的 段 


为 ".rodata..compressed" ° 


接 下 来 的 ".text"、".data" 等 段 就 是 保存 内 核 非 压缩 部 分 的 代码 和 数据 
了 ， 包 括 misc.o、string.0o、cmdline.o、early_serial_console.o 以 及 head_32.o 中 
的 不 属于 段 ".head.text" 的 部 分 。 因 为 内 核 非 压缩 部 分 被 编译 为 位 置 无 关 
(PIC) 代码 ， 所 以 我 们 看 到 其 包含 got 表 。 


综 上 所 述 ，bzImage 的 布局 如 图 3-3 所 示 。 


startup 32、_ 


uncompressed 


compressed 


uncompressed 
(part of head 32.0, 
misc.o, string.o, ...) 


| 
| 


图 


.head.text -TY 


arch/x86/boot/ 
compressed/head 32.5. 


_HEAD 
ENTRY(startup 32) 


.rodata..compress ENDPROC(startup 32) 


(vmlinux.bin.gz) 


vmlinux.bin 
| 
- 十 


got 


bzlmage 


3-3 内核 映像 bzImage 的 布局 


3.3 配置 内 核 


内 核 提 供 了 make menuconfig、make xconfig、make gconfig 等 具有 图 形 
界面 的 配置 方式 。 make menuconfig 是 图 形 界面 配置 方式 中 最 简陋 的 一 种 ， 
但 是 却 非常 方便 易 用 ， 依 赖 也 最 小 。 其 他 如 make xconfig、make gconfig 需 
要 QT、GTK+ 等 库 的 支持 。 在 本 书 中 ， 我 们 使 用 make menuconfig 配 置 内 
核 ， 其 简单 地 基于 终端 的 图 形 界面 是 使 用 ncurses 编 写 的 ， 因 此 需要 安装 
libncurses5-dev， 安 装 方法 如 下 : 


root@baisheng:~# apt-get install libncurses5-dev 


3.3.1 交叉 编译 内 核 设置 


在 默认 情况 下 ， 内 核 构建 系统 默认 内 核 是 本 地 编译 ， 即 编译 的 内 核 是 
运行 在 与 宿主 系统 相同 的 体系 架构 上 。 如 果 是 为 其 他 的 架构 编译 内 核 ， 即 
交叉 编译 ， 我 们 需要 设置 两 个 变量 : ARCH 和 CROSS_COMPILE。 其 中 : 


令 ARCH 指 明 目 标 体系 架构 ， 即 编译 好 的 内 核 运行 在 什么 平台 上 ， 如 


Xx86、arm 或 mips 等 。 


令 CROSS_COMPILE 指 定 使 用 的 交 义 编译 絮 的 前 级 。 对 于 我 们 的 交叉 


工具 链 来 说 ， 其 前 级 是 1686-none-linux-gnu-。 


在 顶层 的 Makefile 中 ， 我 们 可 以 看 到 工具 链 中 的 编译 器 、 链 接 器 等 均 以 
$(CROSS_COMPILE) 作 为 前 绥 


1inux-3.7.4/Makefile : 


AS = $(CROSS COMPILE)a 

LD s CROSS ee 

Ge = ee _COMPILE) gcc 

CPP = $(C -E 

AR = ey COMPILE)a 

NM = $(CROSS COMPILE)n 

STRIP = ee 
OBJCOPY = $(CROSS COMPILE)objcopy 
OBJDUMP = $(CROSS COMPILE)objdump 


可 以 使 用 多 种 方式 定义 这 两 个 变量 ， 比 如 通过 在 环境 变量 中 定义 
ARCH、CROSS_COMPILE; 或 者 每 次 执行 make 时 ， 通 过 命名 行为 这 两 个 
变量 的 赋值 ， 如 : 


make ARCH=i386 CROSS COMPILE=i686-none-linux-gnu- 


也 可 以 直接 更 改 顶层 Makefile。 这 种 方法 比较 方便 ， 但 是 要 小 心 ， 以 锡 
破坏 Makefile 文 件 。 本 书 中 我 们 采用 这 种 方式 ， 将 顶层 Makefile 中 的 如 下 脚 
本 : 


1inux-3.7.4/Makefile : 


ARCH ?= $ (SUBARCH) 
CROSS COMPILE ?= $(CONFIG CROSS COMPILE:"%"=%) 


时 改 为 : 


1Linux-3.7.4/Makefile : 


ARCH R= 3586 
CROSS COMPILE ?= i686-none-linux-gnu- 


3.3.2 ”基本 内 核 配 置 


编译 内 核 的 第 一 步 是 配置 内 核 ， 但 是 在 我 们 使 用 的 这 一 版 的 内 核 中 ， 
有 成 十 上 万 的 配置 项 ， 并 且 很 多 配置 项 彼此 之 间 存 在 大 非常 紧密 的 依赖 天 
系 ， 如 果 从 和 零 开始 一 项 一 项 地 配置 ， 显 然 不 是 一 个 好 办 法 。 


幸运 的 是 ， 在 很 多 情况 下 ， 我 们 都 会 有 一 个 目标 系统 的 老 版 本 内 核 配 
置 文件 ， 而 不 必 每 次 都 从 零 开 始 。 在 此 种 情况 下 ， 首 先 将 已 有 的 内 核 配 置 
文件 复制 到 顶层 目录 下 ， 并 命名 为 .config; 然后 运行 make oldconfig， 其 将 
会 询问 用 户 如 何 处 理 变 动 的 内 核 配置 ， 最 后 用 户 可 以 使 用 make menuconfig 
进行 微调 。 虽 然 内 核 提 供 make oldconfig 的 方法 ， 但 是 这 些 方 法 并 不 是 完美 
的 ， 读 者 需要 小 心 处 理 新 内 核 中 新 增 或 改变 的 配置 项 。 


但 是 也 有 很 多 情况 ， 已 有 配置 并 不 理想 ， 我 们 需要 进行 更 彻底 定制 ， 
或 者 我 们 根本 找 不 到 一 个 合适 的 已 有 配置 。 难 道 我 们 束 别 无 选择 ， 只 能 从 
零 开 始 了 吗 ? 当然 不 是 ， 内 核 构 建 系 统 已 经 为 开发 者 考虑 了 这 些 。 


一 方面 内 核 为 很 多 平台 附带 了 默认 配置 文件 ， 保 存在 arch/ <arch 
>/configs 目 录 下 ， 其 中 <arch> 对 应 具体 的 架构 ， 如 x86、arm 或 者 mips 
等 。 比 如 ， 对 于 x86 架 构 ， 内 核 分 别提 供 了 32 位 和 64 位 的 配置 文件 ， 即 
i386_defconfig 和 x86_64_defconfig; 对 于 arm 架 构 ， 内 核 提供 了 如 NVIDA 的 
Tegra 平 台 的 默认 配置 tegra_defconfig，Samsung 的 S5PV210 平 台 的 默认 配置 
s5pv210_defconfig 等 。 


如 果 我 们 打算 使 用 x86 的 32 位 的 默认 配置 ， 执 行 下 面 命 令 即 可 : 
make i386 defconfig 

如 果 想 使 用 Samsung 的 S5PV210 平 台 的 默认 配置 ， 则 使 用 如 下 命令 : 
make ARCH=arm s5pv210 defconfig 


如 果 对 这 些 内 核 内 置 的 默认 配置 依然 不 满意 ，kbuild 还 提供 了 创建 一 个 
最 小 配置 的 方法 ， 从 某 种 意义 上 讲 ， 这 是 最 彻底 的 定制 方式 了 ， 命 令 如 
下 


make allnoconfig 


执行 该 命令 后 ， 内 核 除了 选中 必 选 项 外 ， 其 余 全 部 不 选 。 我 们 举 个 例 
子 来 展示 这 个 配置 方式 ， 例 如 某 Kconfig 文 件 中 有 如 下 配置 : 


config A 
def bool y 


config B 
def pool y if X86 64 


Contig © 
def tristate y 
select D 


config D 
bool 


config E 
bool “config E" 


config F 
bool veonfig Ee" 
default Y 


如 果 我 们 在 IA32 上 执行 "make allnoconfig"， 则 内 核 构 建 系统 基本 按照 如 
下 规则 处 理 上 述 各 配置 项 。 


令 config A: 无 条 件 选 中 。 


令 config B: 不 会 被 选 中 ， 因 为 平台 不 是 X86_64 架 构 。 


令 config C: 无 条 件 选中 。 另 外 ， 因 为 该 选项 明确 有 要求 选 中 D， 所 以 选 
项 D 也 会 被 选中 。 


令 config EE: 不 会 被 选中 。 


令 configF: 不 会 被 选中 。 虽 然 该 选项 指出 默认 值 "defaulty"， 但 是 注 
意 "default y" 和 "def_bool y" 是 有 本 质 区 别 的 ，"def_bool y" 是 无 条 件 选 
中 ，"default y" 只 是 建议 。 


执行 make allnoconfig 后 ， 生 成 的 配置 文件 .config 如 下 : 


CONFIG A=y 
CONFIG C=y 
CONFIG D=y 
# CONFIG E is not set 
# CONFIG F is not set 


在 本 书 中 ， 我 们 基于 make allnoconfig 的 结果 开始 配置 内 核 ， 命 令 如 
下 : 


vita@baisheng:/vita/build/linux-3.7.4$ make allnoconfig 


接 下 来 各 节 中 ， 我 们 以 这 个 基本 配置 为 基础 ， 按 照 需要 进行 具体 的 配 
置 。 布 望 读 者 可 以 通过 这 个 过 程 的 学 习 ， 能 够 做 到 举一反三 ， 在 具体 的 项 
目 中 进行 最 优 的 配置 。 


333 本 下 处 理 斋 


1. 选 择 处 理 器 型 号 


对 于 x86 架 构 来 说 ， 其 具有 问 后 兼容 性 ， 较 新 的 处 理 器 部 支持 较 早 的 处 
理 器 的 指令 。 因 此 ， 为 较 早 的 处 理 器 开发 的 程序 都 可 以 在 较 新 的 处 理 器 上 
运行 ,但 是 反 过 来 则 不 一 定 了 ， 因 为 较 早 的 处 理 右 当然 不 会 文 持 较 新 的 处 


名 中 的 一 些 指令 


注 


因此 ， 选 择 支 持 越 早 的 处 理 器 ， 则 内 核 承 可 以 在 更 多 的 机 器 上 运行 。 
对 于 很 多 Linux 发 行 版 ， 通 常 就 古 依 照 这 个 原则 。 比 如 Ubuntu12.10 的 内 核 配 
置 支持 的 处 理 器 型 号 为 Pentium Pro (686) ， 这 样 理论 上 可 以 确保 
Ubuntu12.10 可 以 运行 在 Pentium Pro 以 后 的 所 有 系列 机 器 上 。 


如 此 选择 虽然 带 来 了 兼容 性 的 好 处 ， 但 是 付出 的 代价 可 能 就 是 来 失 了 
速度 。 比 如 ， 为 Pentium Pro 编 译 的 内 核 ， 只 针对 Pentium Pro 进 行 了 优化 ， 
显然 不 能 使 用 最 新 处 理 器 中 的 更 高 级 的 指令 。 


对 于 其 他 架构 亦 如 此 ， 甚 至 有 过 之 而 无 不 及 ， 比 如 都 是 ARM 处 理 器 ， 
但 是 如 果 目 标 平台 是 Freescale iMX 系 列 ， 处 理 需 型 号 显然 不 能 选择 Samsung 
的 S3C 系 列 。 


在 Linux 操 作 系 统 中 ， 可 以 使 用 如 下 命令 查看 处 理 右 的 具体 型 与 : 


root@baisheng:~# cat /proc/cpuinfo | grep "model namen 
model name : Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz 
model name : Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz 
model name : Intel(R) Core (ITM) i5-2430M CPU @ 2.40GHz 
model name : Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz 


下 面 是 配置 内 核 文 持 的 处 理 器 型 号 的 步骤 。 


1) 执行 make menuconfig， 出 现 如 图 3-4 所 示 界 面 。 


| 本 工 Processor type and Re ee 


图 3-4 配置 处 理 器 型 号 (1) 


2) 在 图 3-4 中 ， 选 择 菜单 项 "Processor type and features"， 出 现 如 图 3-5 
所 示 界 面 。 


| 本 Processor fanily (Pentium- pro) 3 


图 3-5 配置 处 理 器 型 号 (2) 


3) 在 图 3-5 中 ， 选 择 菜单 项 "Processor family"， 出 现 如 图 3-6 所 示 的 界 
面 o 


[C8) core 2/newer Xeon) 


a2 


图 3-6 配置 处 理 器 型 号 (3) 


4) 以 笔者 的 机 器 为 例 ， 根 据 前 面 察看 的 CPU 信息 ， 显 然 选 择 图 3-6 中 
的 "Core 2/newerXeon" 是 最 适合 的 。 如 果 在 列表 中 没有 与 实际 CPU 型 号 完 
吻合 的 ， 可 选择 与 它 最 接近 的 一 项 。 


2. 配 置 内 核 文 择 SMP 


如 果 机 器 有 多 颗 CPU (包括 多 核 ) ， 为 了 更 好 地 发 挥 多 颗 CPU 的 性 
能 ， 需 要 配置 内 核 文 持 SMP。 下 面 是 配置 内 核 文 持 SMP 的 步 又 。 


1) 执行 make menuconfig， 出 现 如 图 3-7 所 示 的 界面 。 


rocessor type and features ---> 


-Or 


图 3-7 配置 SMP (1) 


2) 在 图 3-7 种 ， 选 择 菜单 项 "Processor type and features"， 出 现 如 图 3-8 


所 示 的 界面 。 


[四 ] ‘ymmetric multi-processing support| 


2 


[s 


图 3-8 ”配置 SMP (2) 


3) 在 图 3-8 中 ， 选 中 "Symmetric multi-processing support" 。 


3.3.4 配置 内 核 文 持 模块 


在 肉 入 式 系统 中 ， 由 于 外 围 设 备 相 对 比较 固定 ， 因 此 ， 在 编译 内 
核 时 ， 基 本 可 以 确定 内 核 需要 文 持 哪 些 特性 ， 例 如 文 持 哪些 硬件 、 文 
持 哪些 文件 系统 等 。 而 对 于 用 在 PC 系统 上 的 内 核 ， 因 为 个 人 计算 机 中 
包含 的 硬件 千差万别 ， 为 了 提供 更 好 的 兼容 性 ， 各 家 Linux 发 行 版 的 内 
核 都 尽 可 能 地 包含 更 多 的 功能 ， 文 持 更 多 的 硬件 。 但 是 ， 如 琳 所 有 的 
功能 模块 和 驱动 全 部 编译 进 内 核 映像 ， 势 必 造 成 内 核 极其 庞大 。 以 作 
者 使 用 的 Ubuntu12.10 发 行 版 为 例 ， 其 内 核 映 像 大 小 为 5MB ， 而 该 发 行 
版 中 包含 的 内 核 模块 的 尺寸 约 为 100MB 左 右 。 也 就 是 说 ， 如 果 把 全 诗 
的 模块 部 编译 进 内 核 映 像 ， 内 核 映 像 的 尺寸 大 约 要 增加 100MB， 而 其 
中 绝 大 部 分 模块 在 特定 的 一 台 机 大 上 是 根本 不 会 用 到 的 。 


除了 尺寸 上 的 考虑 外 ， 更 大 的 灵活 性 也 是 一 方面 。 比 如 ， 开 发 人 
员 在 开发 某 个 驱动 时 ， 如 果 使 用 模块 机 制 ， 只 需 单独 编译 驱动 ， 然 后 
动态 加 载 ， 即 可 进行 调试 ， 而 不 必 重 新 编译 整个 内 核 ， 甚 至 重启 系 


统 。 


因此 ， 在 我 们 编译 的 内 核 中 ， 启 用 内 核 的 动态 加 载 模块 特性 。 下 
面 是 配置 内 核 支持 模块 机 制 的 步 又。 


1) 执行 make menuconfig， 出 现 如 图 3-9 所 示 的 界面 。 


[nm] iene 


3-9 配置 内 核 支 持 模块 (1) 


2) 在 图 3-9 中 ， 选 中 荣 单 项 "Enable loadable module support"， 人 允 
许 内 核 动态 加 载 模块 ， 出 现 如 图 3-10 所 示 的 界面 。 


[ne Mo Tr eunloading 


3-10 配置 内 核 支持 模块 (2) 


3) 在 图 3-10 中 ， 选 中 "Module unloading"， 人 允许 内 核 动 态 伙 载 模 
块 。 


3.3.5 配置 硬盘 控制 锅 豫 动 


一 般 而 言 ，PC 的 根 文件 系统 都 保存 在 硬 强 上 ， 因 此 ， 我 们 需要 配置 内 
核 的 硬盘 驱动 。 在 笔者 写作 这 本 书 时 ， 大 多 数 现代 PC 都 使 用 SATA 接 口 的 做 
盘 ，SAIA 硬 盘 基 本 已 经 全 面 取代 了 IDE 硬 盘 。 因 此 ， 我 们 以 SATA 人 硬盘 为 
例 ， 讨 论 内 核 中 硬盘 驱动 的 配置 。 关 于 SATA 控 制 絮 驱动 的 配置 ， 需 要 从 二 
个 方面 考虑 。 


(1) 硬盘 控制 器 的 接口 


SATA 控 制 器 使 用 的 是 PCI 接 口 ， 挂 在 PCI 总 线 上 ， 所 以 首先 需要 配置 内 


核 支持 PCI 总 线 。 


可 以 使 用 lspci 命 令 查 看 SATA 人 硬盘 的 相关 信息 。 下 面 以 笔者 机 右 为 例 ， 
执行 lspci 命 令 输 出 的 天 于 SATA 控 制 右 的 相关 信息 : 


root@baisheng:~# lspci -V 


00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 
port SATA AHCI Controller (rev 04) (prog-if 01 [AHCI 1.0]) 


Kernel driver in use: ahci 


显然 ， 在 0 号 PCI 总 线 上 ， 有 一 个 SATA 控 制 器 ， 工 作 模 式 为 AHCI， 使 
用 的 内 核 驱动 是 ahci。 


(2) 与 SCSI 层 之 间 的 关系 


在 内 核 中 ，SATA 设 备 被 实现 为 一 个 SCSI 设 备 ， 如 图 3-11 所 示 。 
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SATA Translation 

(libata) 
SATA 
Low Level Device Driver 
(ahci / ata_piix) 


SATA Controller hardware 


SATA Disk 


图 3-11 SATA 子 系统 结构 


因此 ， 虽然 目标 机 器 上 可 能 没有 SCSI 设 备 ， 但 是 如 果 要 支持 SATA 控 制 
人 絮 ， 内 核 也 要 配置 支持 SCSI 。 


(3) 底层 设备 驱动 
在 图 3-11 中 ， 内 核 将 SATA 张 动 从 逻辑 上 划分 为 两 层 : 


令 SATA Translation， 这 一 层 负责 SCSI 和 SATA 协 议 之 间 的 翻译 ， 在 
SATA 张 动 中 被 封装 为 libata 模 块 。 


令 Low Level Device Driver， 在 SATA Translation 层 下 ， 是 直接 面 对 设 备 
的 底层 张 动 。 很 多 SATA 探 制 右 均 提 供 两 种 可 选 模式 : 一 种 是 模拟 传统 的 


IDE， 通 遂 称 为 Compatibility 模 式 ， 这 种 模式 是 为 了 回 后 兼容 那些 较 早 的 不 
文 持 SATA 的 操作 系统 ; 另外 一 种 是 AHCI 模 式 ， 这 种 模式 可 以 提供 更 好 的 性 
能 及 传输 速度 。 对 于 Intel 的 SATA 探 制 器 来 说 ， 内 核 为 这 两 种 不 同 的 模式 分 
别 实现 了 驱动 : ata_piix 和 ahci 。ata_piix 驱 动用 于 Compatibility 模 式 ，ahci 驱 
动用 于 AHCI 模 式 。 


从 kbuild 中 有 天 SATA 的 Kconfig 中 ， 我 们 也 可 以 清楚 地 看 到 SATA 控 制 絮 
对 PCI 和 SCSI 的 依赖 : 


linux-3.7.4/drivers/ata/Kcontfig.: 


menuconfig ATA 
tristate "Serial ATA and Parallel ATA drivers' 


select SCSI 

config SATA AHCI 
tristate "AHCI SATA support" 
depends on PCI 

config ATA PIIX 


tristate "Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support" 
depends on PCI 


先 看 配置 项 ATA， 正 如 配置 中 的 描述 "Serial ATA and Parallel ATA 
drivers"， 这 一 项 对 应 于 SATA 和 PATA 设 备 。 注 意 其 中 用 黑体 标识 的 部 分 ， 
这 一 配置 项 是 依赖 SCSI 的 而 且 ATA 是 选择 (select) 依赖 SCSI。 也 就 是 说 ， 
一 旦 配置 内 核 支 持 ATA 设 备 ，kbuild 将 自动 选中 内 核 的 SCSI 文 持 。 


再 来 看 配置 项 SATA_AHCI 和 ATA_PIIX， 这 两 项 对 应 的 就 是 前 面 所 说 的 
SATA 控 制 器 的 驱动 ，SATA_AHCI 用 于 驱动 AHCI 模 式 ，ATA_PIIX 用 于 驱动 


Compatibility 模 式 。 根 据 上 面 我 们 用 黑体 标示 的 部 分 ， 
两 项 均 要 求 内 核 文 持 PCI 总 线 。 


可 以 清楚 地 看 到 ， 


下 面 我 们 就 具体 配置 这 三 个 部 分 。 


1. 配 置 PCI 总 线 


为 SATA 控 制 絮 使 用 的 是 PCI 接 口 ， 所 以 我 们 首先 来 配置 内 核 支 持 PCI 
总 线 。 


1) 执行 make menuconfig， 出 现 如 图 3-12 所 示 的 界面 。 


Processor type and features ---> 
Power management and ACPI options 


---> 


Executable file formats / Emulations ---> 


图 3-12 配置 PCI 总 线 (1) 


2) 在 图 3-12 中 ， 选 择 菜 单项 "Bus options"， 出 现 如 图 3-13 所 示 的 界面 。 


[W] PCI support 
PCI access mode (Any) ---> 
[ ] FCI Express sypport (NEW) 
「 1 Enable PCI resource re-allocation detection (NEW) 


图 3-13 配置 PCI 总 线 (2) 


3) 在 图 3-13 中 ， 选 中 菜单 项 "PCI support"。PCI 总 线 配置 完毕 


2. 配 置 SCSI 


接 下 来 配置 SCSI。 


1) 执行 make menuconfig， 出 现 如 图 3-14 所 示 的 界面 。 


图 3-14 配置 SCSI (1) 


2) 在 图 3-14 中 ， 选 择 菜 单项 "Device Drivers"， 出 现 如 图 3-15 所 示 的 界 


图 3-15 配置 SCSI (2) 


3) 在 图 3-15 中 ， 选 择 菜单 项 "SCSI device support"， 出 现 如 图 3-16 所 示 
的 界面 。 


图 3-16 配置 SCSI (3) 
4) 在 图 3-16 中 中 "SCSI device support" 和 "SCSI disk support" 
将 它们 都 编译 进 内 核 ， 而 不 是 编译 为 模块 。SCSI 配 置 完毕 。 


， 注 意 
3. 配 置 SATA 控 制 器 驱动 


下 面 来 配置 SATA 控 制 器 驱动 


) 执行 make menuconfig， 出 现 如 图 3-17 所 示 的 界面 


Networki 


evice Drivers 
Firm 


EE : 


图 3-17 配置 SATA 控 制 器 驱动 (1) 


) 在 图 3-17 中 ， 选 择 菜 单项 "Device Drivers"， 出 现 如 图 3-18 所 示 的 界 
面 o 


ER ATA and 
| ultipl 


ee 
FaraLLel ATA drivers 


配置 SATA 控 制 器 驱动 (2) 


图 3-18 


) 在 图 3-18 中 ， 选 择 "Serial ATA and Parallel ATA drivers" (注意 ] 
进 内 核 ， 而 不 是 编译 为 模块 ) ， 


注意 将 它 编 
出 现 如 图 3-19 所 示 的 界面 


民 ATA E A slUnnport (nh 1 


四 * 国 ntel ESB, ICH, PIIX3, PIIX4 PATA/SATA support| 


图 3-19 ”配置 SATA 控 制 器 驱动 (3) 


4) 笔者 的 机 器 使 用 的 是 Intel SATA 控 制 器 ， 所 以 选择 图 3-19 中 的 "AHCI 
SATA support" 和 "Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support"°。 前 
者 是 工作 在 AHCI 模 式 的 Intel SATA 控 制 器 的 驱动 ， 后 者 是 工作 在 
Compatibility 模 式 的 Intel SATA 控 制 器 的 驱动 。 注 意 将 它们 也 都 编译 进 内 
核 * 


至 此 ，SATA 控 制 絮 的 驱动 配置 完成 。 接 下 来 我 们 编译 内 核 ， 并 将 编译 
好 的 内 核 保存 在 目标 系统 的 根 文 件 系 统 的 boot 目 录 下 。 


vita@baisheng:/vita/build/linux-3.7.4$ make bzImage 
vita@baisheng:/vita/build/linux-3.7.4$ mkdir /vita/sysroot/boot/ 


vita@baisheng:/vita/build/linux-3.7.4$ cp arch/x86/boot/bzImage\ 
/vita/sysroot/boot/ 


下 面 测 试 新 编译 的 内 核 。 首 先 在 虚拟 机 的 sda2 分 区 上 创建 boot 目 隶 ， 用 
来 存放 内 核 映 像 : 


root@baisheng-vb:/vita# mkdir boot 
将 新 编译 的 内 核 复制 到 虚拟 机 


vita@baisheng:/vita/sysroot/boots$ scp bzImage \ 
root@192.168.56.101:/vita/boot/ 


并 在 虚拟 机 GRUB 的 配置 文件 中 添加 如 下 局 动 项 : 


/boot/grub/grub.cfg 
menuentry 'vita' { 


set root=' (hda0 ,2) 
linux /boot/bzImage root=/dev/sda2 ro 


注意 将 虚拟 机 的 GRUB 的 配置 文件 grub.cfg 中 的 timeout 都 设置 为 一 个 正 
值 ， 比 如 5s， 这 样 GRUB 才 会 给 我 们 机 会 选择 引导 哪个 系统 。 


后 重新 启动 并 进入 vita 系 统 ， 运 行 结 末 如 图 3-20 所 示 。 


四 自问 11.10[ 正 在 运行 ] - Oracle VM VirtualBox 


[sdal 167?77216 512-bhute logical blocks: (8,.58 6B-8.6096 6GiB) 
[sdal Write Protect is off 
[sdal Write cache: enabled，rFread cache: enabledqd，doesnm't support DPO 


8388608 sda driver: sd 
Doomoooiooloioloiooiolg| 
3506176 sdua2 QQ0000000-0000-90000-0Q900-000000008090 

ne: 


: Suwapperz Not TT he 3 四 


[<cila5O0b>] 
Lx*clizZ4dcaf6é>] 
[xc16962932>] 
[clzdchb52z>] 
[<ci24cc?4>] 
[<c109918f >] 
[<cii9e?d4>] 
EXELZ4EICe3 
Lx<ciia95?7?7>] 
[<*cii9e66Q>] 


panic+Oxrd/Qx158 
mount_block_root+Qx228/0Qx239 
syUSs_sigaction*Qxaz/ Oxf 0 

mount_ rootr+rQx4b/Qxf 
prepare_namespace+Qx1iQe/Qxi4a 
syUs_access+Oxif /Ox30 

kernel init+Qx174/0Qx2Z?0 

do_early param+O0x?7?/Qx?7? 

Pet from kernel thPead+Oxlb“Oxz8 
rest_init+Qx60Qx60 


on) nd) od en) sd) a0) on) so) oo) oO 
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图 3-20 ”配置 SATA 控 制 絮 驱动 后 内 核 运行 情况 


根据 内 核 的 输出 信息 可 见 ， 内 核 已 经 正确 识别 了 SATA 硬 盘 。 但 是 因为 
没有 找到 合适 的 文件 系统 挂 载 sda2 分 区 ， 所 以 在 “抱怨 ”"No filesystem could 
mount root" 后 出 现 了 "panic"。 因 此 ， 在 下 一 小 方 ， 我 们 配置 内 核对 文件 系统 
的 文 持 。 


3.3.6 ”配置 文件 系统 


内 核 文 持 多 种 文件 系统 ， 但 是 由 于 我 们 仅 使 用 Ext4 文 件 系 统 ， 所 
以 这 里 仅 配置 内 核 包 含 Ext4 文 件 系 统 驱 动 模块 。Ext4 驱 动 是 向 后 兼容 
的 ， 也 就 是 说 它 也 可 以 驱动 Ext3 和 Ext2 文 件 系统 。 下 面 是 配置 文件 系统 
的 步骤 。 


1) 执行 make menuconfig， 出 现 如 图 3-21 所 示 的 界面 。 


D 


FT € L WE 
| 国 。” FiLLe systems  --->| 
K el hacki 


图 3-21 配置 文件 系统 (1) 


2) 在 图 3-21 中 ， 选 择 菜 单项 "File Systems"， 出 现 如 图 3-22 所 示 的 
界面 。 
[<g> The Extended 4 (ext4) filesysten 


l 


图 3-22 配置 文件 系统 (2) 


3) 在 图 3-22 中 ， 选 中 配置 项 "The Extended 4(ext4)filesystem"， 并 
将 其 直接 编译 进 内 核 。 


在 格式 化 Ext4 文 件 系统 时 ， 工 具 mke2fs.ext4 会 默认 文 
持 "huge_file" 特 性 ， 而 该 特性 要 求 内 核 支 持 大 于 2TB 的 块 设备 或 文件 ， 
此 ， 我 们 配置 内 核 支 持 这 一 特性 。 


1) 执行 make menuconfig， 出 现 如 图 3-23 所 示 的 界面 。 


General setup ---> 
上 Enable loadable module support ---> 


EnabLe the bLock Layer  ---> 
Processor type and features ---> 


图 3-23 ”配置 支持 大 于 2TB 的 块 设备 和 文件 (1) 


2) 在 图 3-23 中 ， 选 择 菜 单项 "Enable the block layer"， 出 现 如 图 3- 
24 所 示 的 界面 。 


--- Enable the block layer 
[ support for large (2TB+) block devices and files 


] Block layer SG support V4 
] Block layer SG support v4 helper lib 


[ 
[ 
图 3-24 配置 支持 大 于 2TB 的 块 设备 和 文件 (2) 


3) 在 图 3-24 中 ， 选 中 配置 项 "Support for large(2TB+)block devices 


and files"。 


3.3.7 ”配置 内 核 支 持 ELF 文 件 格 式 


在 上 一 节 ， 我 们 配置 了 内 核 支 持 Ext4 文 件 系统 。 但 是 内 核 从 文件 系统 
加 载 文件 ， 仅 支持 文件 系统 还 是 不 够 的 ， 内 核 还 要 支持 具体 的 文件 格式 ， 
当前 Linux 系 统 使 用 的 标准 二 进 制 格式 是 ELF， 因 此 需要 配置 Linux 文 持 ELF 
文件 格式 。 以 下 是 配置 内 核 文 持 ELF 文 件 格式 的 步骤 。 


1) 执行 make menuconfig， 出 现 如 图 3-25 所 示 的 界面 。 


a 
Di 
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图 3-25 配置 内 核 支 持 ELF 文 件 格 式 (1) 


2) 在 图 3-25 中 ， 选 择 菜 单项 "Executable file formats/Emulations"， 出 现 
如 图 3-26 所 示 的 界面 。 


[是 ] ernel support for ELF bf 


naries 
th partial s 
Jpp ' .OUL 

pport for MISC binaries 


图 3-26 配置 内 核 支 持 ELF 文 件 格式 (2) 


3) 在 图 3-26 中 ， 选 中 配置 项 "Kernel support for ELF binaries"。ELE 格 式 
文 持 配 置 完毕 。 


在 配置 内 核 支持 ELF 文 件 格 式 后 ， 我 们 重新 编译 内 核 并 使 用 新 编译 的 内 
核 引 导 vita 系 统 后 ， 系 统 的 输出 如 图 3-27 所 示 。 


命令 合 11.10 [正在 运行 ] - Oracle VM VirtualBox 


scsi 2:0:0:0: CD-ROM UBOX CD-ROM 1.9 PQ: © ANSI: 5 
sd 0:0:0:0: [sda] 16777216 512-bute logyical blocks: (8.58 GB/3.00 GiB) 
Ea 0:0:0:9: [sda]l Write Frotect is of 
sd OQ:0:0:0: [sdal Write cache: enabled, read cache: enabled, doesn’t support DPO 
or FUA 
sda: sdail sdaz 
sd 0O:0:0:0: [sdal] fttached SC3I disk 
[sda2]: couldn' tt mount as ext3 due to feature incompatibilities 
(sda2]J: couldnm tt mount as Ext2 due to feature inmcomDpatibilities 
(sdaz]: INF0: recovery Peduired on readonly filesystem 
(sdaz): write access will be enabled during PECOwenU 
(sdaz): recovery complete 
[| 


FS: Mounted root (ext4 filesyustem) readonly on device 8:;2, 
Freeing unused kernel memory: 336k freed 
kernel panic - not syncing: No init found. Try passing init= option to kernel. 
See Linux Documentation/init.txt for guidance. 
pF : SWapper/Q Not tainted 3.7.4 #30 


[<ciiedB8ab>] 了 panic+Qx?7d/OQx158 

[<cilier1383] ? kernel_inmitt+Ox238~-Oxz7O 
[<cl2za93c2>] ?了 do early param*+Ox??/Qx?77 
[<ciif2377?>3] ? ret from kernel thread+0Oxib/0x28 
[<ciie6fOQO3] ? rest_init+Qx60-0Qx60 
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图 3-27 配置 文件 系统 和 文件 格式 后 内 核 运行 情况 


根据 内 核 输出 的 信息 可 见 ， 内 核 已 经 识别 出 硬盘 的 分 区 ， 也 识别 出 了 
sda2 分 区 使 用 的 文件 系统 ， 并 使 用 Ext4 文 件 系 统 驱 动 成 功 挂 载 了 该 分 区 。 但 
是 内 核 在 “ 报 怨 ”"No init found..." 后 ， 依 然 出 现 了 "panic"。 那 么 ， 这 里 
的 "init" 指 的 是 什么 呢 ? 我 们 看 一 下 内 核 进 入 用 户 空 间 的 过 程 : 


Tops3 7 7 


static noinline void _ init refok rest init (void) 


{ 


kernel thread(kernel init, NULL, CLONE FS | CLONE SIGHAND); 


} 


static int ref kernel init (void *unused) 


{ 


if (ramdisk execute command) { 
if (!run init process(ramdisk execute command)) 
return 0; 
printk (KERN WARNING "Failed to execute gs\n", 
ramdisk execute command); 


if (execute command) { 
if (!run init process (execute command)) 
TatiEn Vy 
printk (KERN WARNING "Failed to execute %s. Attempting " 
"defaults...\n'", execute command); 
if£ (lrun 4nit process("/sbin/init") || 
I!irun init process("/etc/init") || 
!run init process("/bin/init") || 
Irun init process("/bin/sh")) 
return 0; 


panic('"No init found. Try passing init= option to kernel. " 
"See Linux Documentation/init.txt for guidance."); 


函数 kernel_init 首 先 尝试 执行 initramfs 中 的 字符 串 
ramdisk_execute_command 代 表 的 命令 。 日 前 没有 使 用 initramfs， 所 以 这 个 字 
符 串 为 空 ， 于 是 其 继续 尝试 到 根 文件 系统 中 寻找 程序 ， 首 先 其 将 尝试 寻找 


字符 串 execute_command 代 表 的 命令 。 


根据 下 面 代 码 : 


ob eit, We hn fh he Ke pA yb Eh Re 
static char *execute command,; 


statLs nt TN lint. setup lehnar Bt) 


{ 


unsigned int i; 


execute command = str; 


Setup( "nut Lilt SetupD)s 


字符 串 execute_command 代 表 用 户 通 过 内 核 命令 行 参数 "init" 明 确 指定 的 
程序 ， 形 如 : 


/boot/grub/grub .cfg 
menuentry 'vita' { 


Set root=' (hd0 ,2) 
linux /boot/bzImage root=/dev/sda2 ro init=/bin/bash 


Re 使 用 黑体 标识 的 部 分 就 是 明确 告诉 内 核 ， 第 
进程 直接 运行 根 文件 系统 中 目录 /bin 下 的 bash。 如 果 用 户 没有 通过 命令 
行 参数 "init" 指 定 第 一 个 进程 执行 的 程序 ， 进程 将 依次 党 试 执 
行 /sbin、y/etc、/bin 下 的 init， 最 后 党 试 执行 /bin/sh 。 


由 于 目前 根 文件 系统 中 除了 内 核 的 映像 外 没有 任何 文件 ， 因 此 ， 内 核 
找 不 到 任何 程序 ， 所 以 在 报告 "No init found..." 后 出 现 "panic" 了 。 为 了 辅助 
验证 内 核 的 构建 ， 在 下 一 节 我 们 将 构建 一 个 基本 的 根 文 件 系 统 。 


3.4 ”构建 基本 根 文件 系统 


3.4.1 根 文件 系统 的 基本 目录 结构 


Linux 的 根 文件 系统 的 目录 结构 不 是 随意 定义 的 ， 而 是 依照 
Filesystem Hierarchy Standard Group 制定 的 Filesystem Hierarchy Standard 
(FHS) 标准 。 从 服务 器 、 个 人 计算 机 到 舱 入 式 系统 ， 虽 达 不 到 完全 符 
合 ， 但 大 体 上 还 是 遵循 这 个 标准 的 。 


FHS 标 准 规定 的 根 文件 系统 的 顶层 目 录 如 表 3-2 所 示 。 


表 3-2 FHS 根 文件 系统 顶层 的 目录 规范 


目 录 内 容 
/bin 保存 系统 管理 员 与 用 户 均 会 使 用 的 重要 的 命令 
/boot 系统 开机 使 用 的 文件 ， 如 内 核 映 像 和 boot loader 的 相关 文件 
/dev 设备 文件 
/etc 系统 配置 
/lib 重要 的 库 文件 及 内 核 模 块 
/media 可 移动 存储 介质 的 挂 载 点 
/mnt 临时 挂 载 点 ， 当 然 用 户 也 可 以 自行 选择 一 些 临 时 挂 载 点 
/opt 用 户 自 行 安装 软件 的 位 置 ， 通 常用 户 也 会 选择 将 软件 安装 在 /usr/local 目录 下 


/sbin 系统 管理 员 使 用 的 重要 的 系统 命令 


( 续 ) 


目录 内 容 
/tmp 主要 是 正在 执行 的 程序 存放 的 临时 文件 
/usr 包含 系统 中 安装 的 主要 程序 的 相关 文件 ， 类 似 于 MS Windows 操作 系统 中 的 “Program files” 目 录 
ee 针对 的 主要 是 系统 运行 过 程 中 经 常 发 生变 化 的 一 些 数据 ， 比 如 cache 、log、 临 时 的 数据 库 、 打 印 
机 的 队列 等 
/home 用 户 目录 保存 的 地 方 
/root root 用 户 的 用 户 目 录 


主要 用 在 服务 器 版 本 上 ， 是 很 多 服务 器 软件 用 来 保存 数据 的 目录 。 比 如 ，www 服务 器 使 用 的 网 页 


/STV ST 
: 资料 就 可 以 放置 在 /srv/www 目录 下 


FHS 标 准 已 经 将 各 个 目 邓 存放 的 内 容 解 释 得 比较 清楚 了 ， 但 古 还 是 
有 几 个 容易 引起 混 消 的 目 孙 需要 澄清 一 个。 


根 文件 系统 中 主要 有 四 处 存放 可 执行 程序 的 目 
录 : /bin、/sbin、/usr/bin 和 /usr/sbin。 系 统管 理 员 和 普通 用 户 都 使 用 的 
重要 命令 保存 在 bin 目录 下 ， 而 仅 由 系统 管理 员 使 用 的 重要 命令 则 保存 
在 /sbin 目 录 下 。 相 应 的 ， 不 是 很 重要 的 命令 则 分 别 放置 在 /usr/bin 
和 /usr/sbin 目 录 下 。 


同样 的 道理 ， 重 要 的 系统 库 一 般 存 放 在 /ib 目录 下 ， 其 他 的 库 则 存 
放 在 /usr/lib 目 录 下 。 


3.4.2 ”安装 C 库 


几乎 所 有 程序 都 依赖 C 库 ， 它 是 整个 系统 的 基础 ， 因 此 ， 我 们 首先 安装 
C 库 到 根 文件 系统 。 在 2.2.7 世 讨论 编译 构建 系统 的 C 库 时 ， 我 们 看 到 ，C 库 
包含 画 数 库 、 各 种 工具 程序 ， 以 及 开发 所 需 的 头 文件 等 。 而 这 里 的 文件 系 
统 只 是 个 临时 系统 ， 所 以 C 库 中 的 各 种 实用 工具 及 $SYSROOT/usr/share 目 录 
下 的 数据 文件 ， 都 不 需要 安装 。 而 且 这 个 临时 根 文件 系统 亦 不 需要 文 撑 开 
发 ， 所 以 凡是 开发 时 所 需要 的 文件 ， 包 括 头 文件 、 静 态 库 、 局 动 文 件 等 ， 
也 不 需要 安装 。 因 此 ， 最 终 我 们 只 需要 安装 $SYSROOT/Nib 目 录 下 的 动态 库 
及 相应 的 动态 链接 /加 载 器 需要 的 符号 链接 。 


我 们 新 建 一 个 保存 目标 系统 的 根 文 件 系统 的 rootfs 目 录 ， 并 且 按 照 FHS 
标准 的 规定 ， 将 C 库 安装 在 rootfs/lib 目 录 下 ， 命 令 如 下 : 
vita@baisheng:/vitas$s mkdir rootfs 
vita@baisheng:/vitas mkdir rootfs/lib 
vita@baisheng:/vitas cp -d sysroot/lib/* rootfs/lib/ 
除了 Glibc 中 包含 的 C 库 外 ， 在 前 面 编 译 GCC 时 ， 我 们 也 看 到 ，GCC 也 
将 部 分 底层 函数 封闭 到 库 中 ， 有 些 程序 会 使 用 GCC 的 这 些 库 ， 因 此 ， 我 们 
也 将 这 部 分 程序 安装 到 rootfs/ib 目 录 中 。 同 样 ， 我 们 也 只 安装 动态 库 及 其 对 
应 的 运行 时 符号 链接 ， 命 令 如 下 : 


vita@baisheng:/vitas cp -d \ 
cross-tool/i686-none-linux-gnu/lib/lib*.so.*[0-9] rootfs/lib/ 


3.4.3” 安 猜 shell 


在 安装 C 库 后 ， 构 建 基本 的 应 用 程序 的 基础 已 经 具备 了 ， 接 下 来 我 们 需 
要 为 内 核准 备用 户 空间 的 程序 了 。 在 Linux 中 ， 专 门 负责 启动 的 软件 包 ， 如 
System V init 和 Systemd 等 都 提供 一 个 二 进 制 程序 作为 第 一 个 进程 执行 的 用 
户 空间 的 程序 ， 但 是 为 简单 起 见 ， 我 们 使 用 bash shell。 安装 bash 的 命令 如 
下 : 


vita@baisheng:/vita/builds$ tar xvf ../source/bash-4.2.tar.gz 
vita@baisheng:/vita/build/bash-4.2$ ./configure --prefix=/usr \ 
--bindir=/bin --without-bash-malloc 
vita@baisheng:/vita/build/bash-4.2$ make 
vita@baisheng:/vita/build/bash-4.2$ make install DESTDIR=$SYSROOT 


这 里 有 一 点 需要 解释 一 下 ， 我 们 虽然 定义 了 环境 变量 DESTDIR 为 
$SYSROOT， 但 是 由 于 bash 的 Makefile 中 有 如 下 脚本 : 


bash-4.2/Makefile : 


DESTDIR = 


而 Makefile 中 的 这 个 定义 优先 级 要 比 环境 变量 的 高 ， 所 以 我 们 还 需要 通 


过 命令 行 参数 再 次 指定 安装 日 录 为 $SYSROOT 。 
使 用 如 下 命令 将 bash 安 装 到 rootfs 中 : 


vita@baisheng:/vitas mkdir rootfs/bin 
vita@baisheng:/vitas$ cp sysroot/bin/bash rootfs/bin/ 


除了 安装 程序 bash 外 ， 当 然 还 需要 安装 bash 依 赖 的 动态 库 。 因 此 ， 为 了 
检查 可 执行 程序 或 动态 库 的 依赖 ， 我 们 编写 了 一 个 脚本 1dd; 


/vita/cross-tool/bin/ldd: 
#!/bin/bash 


LIBDIR="${SYSROOT}/lib ${SYSROOT}/usr/lib 
$ {CROSS TOOL}/${TARGET}/1ib" 


find() { 
for” & Ln SLIBDIR;y qd6 
found=u" 
if [ -f "${d}/$1" ]; then 
found="${d}/$1" 
break 
fi 
done 


df [mn vfound, J] Tien 


Drintf "Sa Sy SNn™ Wm SL Eound 
else 
Drintf "aass sw (not found) \a™ mn $1 


和 


} 


readelf -d $1 | grep NEEDED \ 
| sed -r -e 's/.*Shared library:[ ]+\[(.*)\]/\1l/;' AN 
| while read lib; do 
find $1ib 
done 


并 为 该 脚本 增加 了 可 执行 权限 : 
vita@baisheng:/vita/cross-tool/bins$s chmod a+x ldd 


使 用 ldd 脚 本 查看 bash 依 赖 的 动态 库 : 


vita@baisheng:/vitas ldd rootfs/bin/bash 
libdl.so.2 => /vita/sysroot/lib/libdl.so.2 
Libaco BBGnl 
/vita/cross-tool/i686-none-linux-gnu/lib/libgcc s.so.1 
1iDe Boe sx /vita/ Byveroot/libp/libDe B06 


根据 脚本 1dd 的 输出 可 见 ，bash 依 赖 动态 库 libdl、1libc 和 libgcc_s.so.1， 而 
这 几 个 库 都 包含 在 C 库 中 ， 我 们 都 已 经 安装 了 。 


在 3.3.7 玫 我 们 看 到 ， 如 采用 户 没有 通过 内 核 命 令 行 参 数 "init" 指 定 第 一 
个 进程 运行 的 用 户 空间 的 程序 ， 则 内 核 依次 尝试 执行 目录 /sbin 、/etc 、/bin 
下 的 init， 最 后 尝试 执行 目录 /bin 下 的 sh。 因 此 ， 我 们 在 目录 /bin 下 建立 一 个 
指向 bash 的 符号 链接 sh， 而 且 ， 这 个 符号 链接 也 是 FHS 标 准 要 求 的 。 


vita@baisheng:/vita/rootfs/bins$s ln -s bash sh 


3.4.4” 安 疼 根 文件 系统 到 目标 系统 


接 下 来 ， 我 们 需要 将 文件 系统 安装 到 虚拟 机 上 ， 来 配合 内 核 进行 启 
动 。 

当然 ， 如 果 为 了 减少 共享 库 和 二 进 制 可 执行 文件 的 大 小 ， 可 以 使 用 
i686-none-linux-gnu-strip 命 令 删 除 ELF 中 运行 时 不 需要 的 符号 ， 命 令 如 下 : 


vita@baisheng:/vitas$ i686-none-linux-gnu-strip rootfs/lib/* \ 
rootfs/bin/* 


但 是 一 定 不 要 对 crt*.o 等 这 些 局 动 文件 进行 strip， 因 为 这 样 会 删除 目标 
文件 的 符号 表 ， 导 致 链接 郁 在 链接 时 找 不 到 符号 。 


接 下 来 我 们 使 用 scp 命 令 ， 将 文件 系统 复制 到 虚拟 机 上 “。 因 为 命令 scp 会 
跟随 符号 链接 ， 因 此 ， 我 们 首先 将 文件 系统 打包 ， 然 后 再 使 用 scp 命 令 进行 


复制 : 


vita@baisheng:/vita/rootfss$ tar zcvf ../rootfs.tgz * 
vita@baisheng:/vita/rootfs$ scp ../rootfs.tgz \ 
root@192.168.56.101:/vita/ 


在 复制 完成 后 ， 在 虚拟 机 上 解 开 压 缩 包 : 


root@baisheng-vb:/vita# tar xvf rootfs.tgz 


重启 系统 后 ， 如 果 一 切 顺 利 ， 用 户 空 间 的 程序 /bin/sh 会 顺利 运行 ， 如 图 
3-28 所 示 。 


合 全 全 11.10 [正在 运行 ] - oractle VM VirtualBox 


.00: ATAPI: UBOX CD-ROM, 1.0, max UDMA/133 
.O00: configured for UDMA/33 
: 3ATA link up 3.0 Gbps (Sstatus 123 SControl 300) 
ATh-6: UBOXK HARDDPISKEK，1.9，max UDMhZz133 
: 16r7rrzl6 sectors, multi iz28: LBA48 NCQ Cduepth 31x32) 
: conf igured for UPpMAr133 
:0:0:0: Direct-fccess ATA UB0x HARDDISK 1.9 PQ: @ ANSI: 5 
:9:9: CD-ROM UBDOX CD-ROM 1.9 PQ: @ ANSI: 5 
:9:9: [sdua]l 167?7?7?216 512-bute logyical blocks: (8.58 GB/8.00 GiB) 
:0:0: [sda] Write Protect is off 
:©: [sda] Write cache: enabled, read cache: enabled, doesn’t support DPD 


: sdal sdaz 
:0: [sdal] fttached SC3SI disk 
ExT4-fs tsda2): couldn’t mount as ext3 due to feature incompatibilities 
EXT4-fs Csda2): couldn’t mount as ext2 due to feature incompatibilities 
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) 
UFS: Mounted root (ext4 filesystem) readonly on device 8:2. 


: Cannot set terminal process group (-1): Inappropriate ioctl] for device 
: no job control in this shell 
-4.2# tsc: Refined TSC clocksource calibration: 2370.,132 MHz 


全 上 多量 站 条 | 从 加 右 ctrl 


图 3-28 系统 启动 后 进入 shell 


至 此 ,一 个 基本 的 内 核 已 经 构建 完成 了 。 它 可 以 运行 在 x86 体 系 架构 
上 ， 可 以 驱动 mntel 的 SATA 硬 盘 ， 可 以 识别 EXT 系 列 文件 系统 ， 并 内 置 ELF 
文件 加 载 器 ， 最 后 成 功 运行 了 用 户 空间 的 程序 bash 。 


当然 ， 这 仅仅 是 个 开始 ， 我 们 才刚 刚 上 路 。 读 考 可 以 根据 需要 继续 扩 
展 内 核 功能 ， 比 如 ， 后 面 为 了 文 持 网 络 ， 我 们 配置 内 核 文 持 TCP/AP 协 议 、 
配置 内 核 文 持 网 卡 驱 动 等 。 但 是 ， 通 过 这 一 过 程 ， 我 们 也 看 到 ， 从 头 开始 
编译 一 个 内 核 并 非 如 想象 般 困 难 。 虽 然 内 核 包 罗 万 象 ， 文 持 不 同 的 体系 结 
构 ， 有 着 成 干 上 万 的 选项 ， 包 含 数 不 清 的 驱动 ， 这 些 部 让 内 核 看 起 来 无 比 


复 洒 ， 但 是 不 要 被 这 些 表象 迷惑 ， 只 要 以 目标 为 导 癌 ， 再 加 上 一 点 耐心 ， 
配置 一 个 高 效 的 内 核 不 再 是 梦 。 


第 4 章 ”构建 initramfs 


一 般 而 言 ， 昌 面 、 服 务 右 等 通用 系统 都 使 用 initramfs。 部 分 价 入 
式 系统 中 ， 也 会 使 用 iniramfs， 甚 至 有 的 使 用 initramfs 作 为 最 终 的 根 文 
件 系 统 。 那 么 什么 是 iniramfs 呢 ?很 难 用 一 句 话 将 iniramfs 的 作用 描述 
清楚 ， 或 许可 以 将 initramfs 定 位 为 内 核 通 往 根 文 件 系 统 的 桥梁 。 


但 是 ， 在 上 一 章 中 我 们 看 到 ， 在 没有 使 用 initramfs 的 情况 下 ， 内 
核 也 已 经 成 功 挂 载 了 根 文件 系统 并 进入 了 用 户 空间 。 因 此 ， 我 们 不 森 
会 产生 疑问 : 既然 内 核 不 用 借助 这 座 桥梁 束 能 到 达 彼 岸 ， 为 什么 还 要 


使 用 initramfs 呢 ? 是 不 是 多 此 一 举 ? 


这 一 章 就 来 回答 这 个 问题 。 本 章 先 后 讲述 了 为 什么 要 使 用 
initramfs; 接着 阐述 了 initramfs 的 工作 原理 ; 然后 从 零 开 始 ， 构 建 了 一 
个 initramfs， 其 中 将 讨论 内 核 如 何 做 到 动态 加 载 用 户 空间 的 驱动 ， 如 
何 让 冷 插 拔 (coldplug) 设备 也 如 热 插 拔 (hotplug) 设备 一 样 ， 可 以 
动态 加 载 用 户 空 间 的 驱动 等 等 ， 最 后 讨论 如 何 从 initramfs 切 换 到 真正 
的 根 文件 系统 。 


4.1 为 什么 需要 initramfs 


在 引导 过 程 的 最 后 ， 内 核 司 动 第 一 个 用 户 进 程 ， 内 核 需要 访问 根 
文件 系统 ， 加 载 相应 的 可 执行 程序 。 这 束 要 求 内 核能 够 正确 驱动 根 文 
件 系 统 所 在 设备 。 所 以 在 上 一 章 中 ， 我 们 将 SATA 伺 盘 驱 动 编译 进 了 内 
核 ， 为 的 就 古 内 核 可 以 正确 驱动 便 副 。 


寻找 根 文件 系统 的 过 程 中 ， 我 们 需要 考虑 以 下 两 种 情况 。 


第 一 ， 除 非 是 一 个 专用 系统 ， 目 标 系统 的 硬件 平台 是 固定 不 变 
的 ， 否 则 ， 对 于 一 个 通用 操作 系统 ， 比 如 Linux 的 桌面 发 行 版 ， 将 运行 
在 各 种 不 同 的 硬件 平台 上 。 因 此 ， 根 文件 系统 可 能 存储 在 各 种 各 样 的 
介质 上 ， 比 如 IDE 硬 盘 、SAIA 硬 盘 、SCSI 人 硬盘 、Flash 存 储 器 ， 以 及 随 
着 技术 的 发 展 ， 不 断 出 现 的 新 的 存储 设备 。 为 了 能 够 兼容 更 多 的 硬件 
平台 ， 显 然 系统 需要 支持 尽 可 能 多 的 存储 设备 。 但 是 如 果 将 所 有 这 些 
设备 的 驱动 全 部 编译 进 内 核 ， 显 然 不 是 一 个 好 办 法 。 因 为 对 于 某 个 特 
定 的 硬件 平台 ， 可 能 只 需要 一 个 驱动 即 可 ， 内 核 中 的 其 他 驱动 根本 用 
不 上 ， 将 它们 编译 进 内 核 只 会 徒 增 内 核 的 尺寸 、 占 用 内 存 空间 ， 尤 其 
对 于 一 些 内 存 或 者 存储 介质 空间 有 限 的 设备 ， 这 个 问题 尤为 明显 。 于 
是 将 这 些 张 动 编译 为 模块 ， 存 储 在 根 文 件 系 统 中 ， 按 需 载 入 内 存 是 一 
个 解决 问题 的 办 法 。 


第 二 ， 根 文件 系统 可 能 不 在 一 个 简单 的 硬 僵 上 ， 比 如 当 使 用 磁 甬 
阵列 RAID 时 ， 根 文件 系统 可 能 横 跨 几 个 存储 设备 ， 或 者 根 文 件 系统 在 
某 个 网 络 设备 上 。 以 使 用 NFS 挂 载 根 文件 系统 为 例 ， 除 了 要 文 持 网 卡 


驱动 外 ， 还 要 进行 网 络 配 置 ， 甚 至 还 要 进行 网 络 认 证 。 某 些 根 文件 系 
统 经 过 压缩 、 加 密 ， 在 挂 载 前 需要 解压 缩 、 解 密 等 操作 。 如 采 这 些 都 
由 内 核 处 理 ， 将 会 使 内 核 变 得 异 间 复杂， 继而 可 能 导致 内 核 的 稳定 
性 、 可 靠 性 、 灵 活性 等 一 系列 的 问题 。 因 此 ， 将 复杂 的 操作 移 到 用 户 
空间 是 解决 上 述 问 题 的 一 个 思路 。 


但 是 ,无论 是 将 驱动 编译 为 模块 ， 还 古 将 处 理 如 RAID 挂 载 的 程序 
存储 在 文件 系统 上 ， 都 会 导致 一 个 鸡 和 蛋 的 问题 : 内 核 要 加 载 这 些 模 
块 或 者 运行 这 些 程序 才能 正确 识别 根 文件 系统 所 在 的 设备 ， 但 十 保 存 
这 些 模块 或 者 程序 的 根 文件 系统 又 存储 在 这 些 设备 上 。 


为 了 解决 上 述 问题 ， 内 核 开 发 者 们 设计 了 initramfs 机 制 。initramtfs 
是 一 个 临时 的 文件 系统 ， 其 中 包含 了 必要 的 设备 如 人 硬盘、 网卡、 文件 
系统 等 的 驱动 以 及 加 载 驱动 的 工具 及 其 运行 环境 ， 比 如 基本 的 C 库 ， 
动态 库 的 链接 加 载 器 等 等 。 同 时 ， 那 些 处 理 根 文件 系统 在 RAID、 网 络 
设备 上 的 程序 也 存放 在 initramfs 中 。 由 第 三 方程 序 (如 Bootloader) 负 
责 将 initramfs 从 硬盘 效 载 进 内 存 。 以 张 动 硬 盘 为 例 ， 内 核 就 不 必 再 从 
硬盘 ， 而 是 从 已 经 加 载 到 内 存 的 initramfs 中 获取 硬盘 控制 器 等 相关 驱 
动 了 ， 继 而 可 以 驱动 硬盘 ， 访 问 硬盘 上 的 根 文件 系统 ， 从 而 解决 了 前 
面 提 到 的 鸡 和 和 蛋 的 矛盾 。 


在 初始 化 的 最 后 ， 内 核 运行 initramfs 中 的 init 程 序 ， 该 程序 将 探测 
硬件 设备 、 加 载 豫 动 ， 挂 载 真 正 的 文件 系统 ， 执 行文 件 系统 


的 /sbiminit， 进 而 切换 到 真正 的 用 户 空间 。 真 正 的 文件 系统 挂 载 后 ， 
initramfs 即 完成 了 使 命 ， 其 占用 的 内 存 也 会 被 释放 。 


4.2 initramfs 原 理 探讨 


在 2.4 以 及 更 早 版 本 的 内 核 中 ， 内 核 使 用 的 是 initrd 。initrd 是 基于 ramdisk 
技术 的 ， 而 ramdisk 就 是 一 个 基于 内 存 的 块 设备 ， 因 此 initrd 也 具有 块 设备 的 
一 切 属性 。 比 如 initrd 容 量 是 固定 的 ， 一 旦 创建 initrd 时 设 定 了 一 个 大 小 ， 就 
不 能 再 进行 动态 调整 。 而 且 ， 如 同 块 设备 一 样 ，initrd 需 要 按照 一 定 的 文件 
系统 格式 进行 组 织 ， 因 此 制作 initrd 时 需要 使 用 如 mke2fs 这 样 的 工具 “格式 
化 ”initrd， 访 问 initrd 时 需要 通过 文件 系统 驱动 。 更 重要 的 是 ， 虽 然 initrd 是 
一 个 伪 块 设备 ， 但 是 从 内 核 的 角度 看 ， 其 与 真实 的 块 设备 并 无 区 别 ， 因 
此 ， 内 核 访问 initrd 也 需 使 用 缓存 机 制 ， 显 然 这 是 多 此 一 举 的 ， 因 为 本 号 
initrd 就 在 内 存 中 。 


鉴于 ramdisk 机 制 的 种 种 限制 ，Linus Torvalds 提 出 了 一 个 想法 : 能 和 否 将 
cache 当 作 一 个 文件 系统 直接 挂 载 使 用 ? 基于 这 个 想法 ，Linus Torvalds 基 于 
已 有 的 缓存 机 制 实现 了 ramfs。ramfs 与 ramdisk 有 着 本 质 的 区 别 ，ramdisk 本 
质 上 是 基于 内 存 的 一 个 块 设 备 ， 而 ramfs 是 基于 缓存 的 一 个 文件 系统 。 因 
此 ，ramfs 去 除了 前 述 块 设备 的 一 些 限制 。 比 如 ，ramfs 根 据 其 中 包含 的 文件 
大 小 可 自由 伸缩 ; 增加 文件 时 ， 自 动 分 配 内 存 ， 删除 文件 时 ， 自 动 释放 内 
存 。 更 重要 的 是 ，ramfs 是 基于 已 有 的 缓存 机 制 ， 因 此 不 必 再 像 ramdisk 那 样 
需要 和 缓存 之 间 进 行 多 余 的 复制 一 环 。 


伴随 着 ramfs 的 出 现 ， 从 2.6 开 始 ， 内 核 开 发 人 员 基 于 ramfs 开 发 了 
initramfs 替 代 initrd。 那 么 initramfs 是 怎样 工作 的 呢 ? 


当 2.6 版 本 的 内 核 引 导 时 ， 在 挂 载 真 正 的 根 文件 系统 之 前 ， 首 先 将 挂 载 
一 个 名 为 rootfs 的 文件 系统 ， 并 将 rootfs 的 根 作为 虚拟 文件 系统 目录 树 的 总 
根 。 那 么 为 什么 要 使 用 rootfs 这 人 么 一 个 中 间 过 程 呢 ? 原因 之 一 还 是 为 了 解决 
鸡 和 和 蛋 的 问题 。 内 核 需 要 根 文件 系统 上 的 驱动 以 及 程序 来 驱动 和 挂 载 根 文 
件 系 统 ， 但 是 这 些 驱 动 和 程序 有 可 能 没有 编译 进 内 核 ， 而 在 根 文件 系统 
上 。 如 采 不 借助 第 三 方 ， 内 核 是 没有 办 法 挂 载 真正 的 根 文件 系统 的 。 而 
rootfs 里 然 名 称 为 rootfs， 但 是 并 不 是 什么 新 的 文件 系统 ， 事 实 上 ， 其 束 是 一 
个 ramfs， 只 不 过 换 了 一 个 名 称 。 换 句 话 说，rootfs 是 在 内 存 中 的 ， 内 核 不 需 
要 特殊 的 驱动 束 可 以 挂 载 rootfs， 所 以 内 核 使 用 rootfs 作 为 一 个 过 渡 的 桥梁 。 


在 挂 载 了 rootfs 后 ， 内 核 将 Bootloader 加 载 到 内 存 中 的 initramfs 中 打包 的 
文件 解压 到 rootfs 中 ， 而 这 些 文件 中 包含 了 驱动 以 及 挂 载 真正 的 根 文件 系统 
的 工具 ， 内 核 通 过 加 载 这 些 驱 动 、 使 用 这 些 工 具 ， 实 现 了 挂 载 真 正 的 根 文 
件 系 统 。 此 后 ，rootfs 也 完成 了 历史 使 命 ， 被 真正 的 根 文件 系 统 窗 埋 
(overmount) 。 但 是 rootfs 作 为 虚拟 文件 系统 目录 树 的 总 根 ， 并 不 能 被 和 扼 
载 。 但 是 这 没有 关系 ， 前 面 我 们 已 经 谈 到 了 ，rootfs 基 于 ramfs， 删 除 其 中 的 
文件 即 可 释放 其 占用 的 空间 。 


4.2.1 ” 挂 载 rootfs 


在 讨论 具体 的 挂 载 rootfs 时 ， 因 为 涉及 了 一 些 文件 系统 相关 的 概念 ， 因 
此 ， 为 了 更 好 地 理解 文件 系统 相关 的 概念 ， 我 们 有 必要 先 来 了 解 一 下 文件 
系统 的 物理 组 织 结构 ， 以 期 对 这 些 抽象 的 概念 有 个 具体 的 认识 。 


以 ExtX (X=2,3,4) 文件 系统 为 例 ， 其 在 存储 介质 上 按照 图 4-1 所 示 进 行 
组 织 。 虽 然 用 于 不 同 操 作 系统 的 文件 系统 其 物理 存储 结构 是 不 同 的 ， 但 是 
Linux 的 虚拟 文件 系统 通过 为 这 些 文件 系统 建立 中 间 适 配 层 ， 模 拟 这 里 介绍 
的 概念 来 实现 对 这 些 文件 系统 的 支持 。 
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File Directory a 


Inode | File/Dir Name 
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图 4-1 ExtX 文 件 系 统 的 组 织 结 构 


ExtX 文 件 系 统 使 用 块 (Block) 作为 基本 存储 单元 。ExtX 文 持 1024、 
2048 和 4096 字 节 大 小 的 块 ， 块 的 大 小 是 在 创建 文件 系统 时 指定 的 ， 如 果 没 
有 明确 指出 ，mke2fs 将 使 用 默认 大 小 。ExtX 文 件 系 统 将 整个 分 区 分 成 多 个 
块 组 (Block Group) ， 除 了 最 后 一 个 块 组 ， 其 他 块 组 都 包含 相同 数量 的 
块 。 下 面 介 绍 每 个 块 组 包含 的 部 分 。 


(1) 超级 块 (Super Block) 


超级 块 接 述 整个 文件 系统 的 信息 ， 包 括 Inode 辟 数 ， 空 则 Inode 数 量 ， 
个 块 组 包含 的 Inode 的 数量 ， 块 的 总 数 ， 空 用 块 的 数量 ， 每 个 块 组 包含 的 块 
的 数量 ， 块 的 大 小 ; 挂 载 的 次 数 、 最 近 一 次 挂 载 的 时 间 等 。 


(2) 块 组 描述 符 (Group Descriptors) 


块 组 措 述 符 包 含 所 有 块 组 的 描述 。 每 个 块 组 摘 述 符 存 储 一 个 块 组 的 描 
述 信息 ， 包 括 块 组 中 块 位 图 所 在 的 块 、 索 引 节 点 位 图 所 在 的 块 、 索 引 市 后 
表 所 在 的 块 等 A 有 


(3) 块 位 图 \Block Bitmap) 


块 位 图 用 来 描述 块 组 中 哪些 块 已 用 、 哪 些 块 空间 。 其 中 每 个 位 对 应 本 
块 组 中 的 一 个 块 ， 这 个 位 为 1 表示 该 块 已 用 ， 为 0 表示 该 块 空间 可 用 。 


(4) 索引 节点 位 图 (Inode Bitmap) 


和 块 位 图 类 似 ， 索 引 市 点 位 图 用 来 摘 述 索引 方 点 表 中 哪些 Inode 已 用 、 
哪些 Inode 空 | 内。 其 中 每 个 位 对 应 索引 节点 位 图 中 的 一 个 Inode， 这 个 位 为 1 
表示 该 mode 已 用 ， 为 0 表示 该 Inode 空 了 可 用 。 


(5) 索引 节点 表 (Inode Table) 


一 个 文件 除了 需要 存储 数据 以 外 ， 一 些 描述 信息 也 需要 存储 ， 如 文件 
类 型 (常规 文件 、 目 录 等 ) 、 权 限 、 文 件 大 小 、 创 建 /修改 /访问 时 间 等 ， 这 


些 信息 存储 在 mode 中 而 不 是 数据 块 中 。 每 个 文件 都 有 一 个 对 应 的 Inode， 一 
个 块 组 中 的 所 有 Inode 组 成 了 索引 节点 表 。 除 了 文件 属性 信息 外 ，Inode 中 还 
记录 了 存储 文件 数据 的 数据 块 。 


(6) 数据 块 (Data Block) 


数据 块 中 存储 的 惑 是 文件 的 数据 。 但 是 对 于 不 同 的 文件 类 型 ， 数 据 块 
中 存储 的 内 容 是 不 同 的 ， 以 第 规 文件 和 目录 为 例 : 


令 对 于 常规 文件 ， 数 据 块 中 存储 的 古文 件 的 数据 。 


令 对 于 目录 ,数据 块 中 存储 的 是 该 目录 下 的 所 有 文件 名 和 子 目 好 名 。 


当然 了 ， 不 是 所 有 的 文件 都 需要 数据 块 ， 如 设备 文件 、socket 等 特殊 文 
件 将 相关 信息 全 部 保存 在 mode 中 ， 就 不 需要 数据 块 存储 数据 。 


因为 超级 块 和 块 组 描述 符 征 文件 系统 的 关键 信息 ， 所 以 每 个 块 组 中 都 
包含 一 份 见 余 的 备份 。 ExtX 文 件 系 统 也 人 允许 在 某 些 特殊 的 情况 下 ， 除 了 第 0 
个 块 组 外 ， 其 余 的 块 组 可 以 不 包含 超级 块 和 块 组 描述 符 的 备份 。 用 户 在 创 
建文 件 系统 时 可 以 通过 命令 行 参数 告诉 工具 mke2fs 。 


Linux 的 虚拟 文件 系统 将 文件 系统 组 织 为 树 形 结构 。 在 初始 化 阶段 ， 内 
核 挂 载 rootfs 文 件 系 统 ， 虚 拟 文件 系统 从 无 到 有 ，rootfs 的 根 作 为 虚拟 文件 系 
统 这 棵 大 树 中 的 第 一 个 太 态 ， 目 然 成 为 所 有 后 来 创建 的 节操 的 和 祖先。 也 整 
征 说 ， 虚 拟 文件 系统 目 永 树 的 根 束 是 rootfs 的 根 。 


本 质 上 ，rootfs 就 是 一 个 ramfs 文 件 系 统 ， 根 据 下 面 rootfs 的 文件 系统 类 
型 的 定义 就 可 看 出 这 一 点 : 


linux-3.7.4/fs/ramfs/inode.c: 


static struct file system type rootfs fs type = { 


.name ww EOOtEen 
.mount = rootfs mount, 
.kill sb = kill litter super, 


有 


static struct dentry *rootfs mount (struct file system type 
*fs type, int flags, const char *dev name, void *data) 


return mount nodev(fs type, flags|MS NOUSER, data, 
ramfs fill super); 


根据 rootfs 中 mount 的 具体 实现 rootfs_mount 可 见 ， 创 建 rootfs 超 级 块 
使 用 的 函数 恰恰 是 创建 ramfs 文 件 系统 的 函数 ramfs_fill super， 这 从 侧面 表 
明了 rootfs 束 是 ramfs 。 


在 内 核 引 导 过程 中 ， 将 调用 mnt_init 挂 载 rootfs， 代 码 如 下 所 示 : 


linux-3.7.4/fs/namespace.c: 


verd nit Mint LHLE(VOLG) 


{ 


Latt roobtatys 
init mount 七 ee() ; 


mnt_init 首 先 调用 init_rootfs 回 内 核 中 注册 了 rootfs 文 件 系 统 ， 代 人 码 如 下 
所 示 : 


linux-3.7.4/fs/ramfs/inode.c: 


127 TnL TInt roottes (vord) 


err = register filesystem(&rootfs fs type); 


然后 ，mnt_init 调 用 init_mount_tree 挂 载 rootfs， 代 码 如 下 所 示 : 


linux-3.7.4/fs/namespace.c: 
static void init init mount tree(void) 


l 


struct vfsmount *mnt; 
struct mnt namespace *ns; 
BEruct Death TOD: 


mt = do kern mount ("rootfs",; 0, "rootfs",; NULL); 


root .mnt = mnt,; 
root .dentry = mnt->mnt root,; 


set fs pwdl(current->fs, &root); 
set £8 ZOOC (CUrEent->ES CEOOBYS 


挂 载 rootfs 的 过 程 是 由 do_kern_mount 来 完成 的 ， 该 函数 所 作 的 工作 主要 
有 以 下 几 个 方面 。 


(1) 创建 代表 rootfs 的 mount 


Linux 的 文件 系统 是 按照 树 形 组 织 的， 不 同 的 文件 系统 都 可 以 挂 载 到 这 
个 树 中 的 任何 一 个 目 孙 上 来 。 内 核 使 用 数据 结构 mount 记 录 具 体 的 文件 系统 
与 虚拟 文件 系统 这 棵 大 树 之 间 的 关系 ，mount 起 到 一 个 承上启下 的 作用 ， 其 
中 的 mnt_mountpoint 指 同文 件 系 统 的 挂 载 点 ，mnt_parent 指 回 挂 载 点 所 在 文 
件 系统 的 mount，mnt_root 指 向 要 挂 载 的 文件 系统 的 根 。 所 以 do_kern_mount 
需要 为 rootfs 创 建 一 个 mount， 因 为 rootfs 是 整个 虚拟 文件 系统 中 第 一 个 挂 载 
的 文件 系统 ， 所 以 这 个 mount 实 例 是 没有 父亲 的 ， 其 指向 父 杀 mount 成 员 的 
mnt_parent 指 回 其 自身 ， 指 癌 rootfs 挂 载 点 的 成 员 mnt_mountpoint 指 向 rootfs 


自己 的 根 mnt_root 。 


(2) 创建 rootfs 的 超级 块 


超级 块 用 于 描述 整个 文件 系统 信息 ， 某 种 意义 上 ， 超 级 块 就 代表 了 整 
个 文件 系统 ， 所 以 挂 载 文件 系统 时 ， 需 要 创建 超级 块 。 对 于 一 个 常规 的 文 
件 系统 ， 内 核 将 从 存储 介质 上 读 入 超级 块 信息 。 但 是 ramfs 是 一 个 基于 内 存 
的 文件 系统 ， 并 不 存在 所 请 的 存储 介质 ， 但 是 前 面 我 们 讨论 的 ExtX 的 文件 
系统 的 基本 概念 依然 是 适用 的 ，ramfs 虽 然 不 能 从 存储 介质 上 读 入 超级 块 信 
轧 ， 但 是 会 模拟 出 一 个 超级 块 。 


(3) 创建 rootfs 根 节点 的 Inode 


内 核 也 需要 从 文件 系统 中 读 入 rootfs 文 件 系 统 根 节 点 的 Inode 信 息 。 但 
， 与 创建 超级 块 同样 的 道理 ， 对 于 ramfs 来 说 ， 也 是 在 内 存 中 模拟 一 个 根 


是 
节点 的 Inode 信 息 。 


(4) 创建 rootfs 根 节点 的 dentry 


虽然 在 文件 系统 中 ， 每 个 文件 都 有 一 个 Inode (对 于 那些 没有 的 ，Linux 
将 模拟 Inode， 以 使 这 些 文件 系统 能 够 挂 载 到 虚拟 文件 系统 中 ) ， 但 是 这 个 
Inode 主 要 是 记 杂 文件 的 数据 块 以 及 属性 信息 ， 而 并 没有 记录 文件 间 关 系 的 
言 息 。 所 以 ， 内 核 设计 了 结构 体 dentry，dentry 中 记录 了 该 文件 的 父 节 点 和 
子 市 态 ， 从 而 可 以 将 文件 挂 载 到 虚拟 文件 系统 树 中 。dentry 在 物理 存储 介质 
中 并 没有 对 应 的 实体 ， 而 只 存在 于 内 存 中 。 为 了 提高 搜索 文件 的 效率 ， 内 
核 会 缓存 文件 系统 中 最 近 访 问 的 dentry 。 


挂 载 rootfs 后 ， 内 核 初始 虚拟 文件 系统 的 结构 如 图 4-2 所 示 。 


| rootfs mount 
: super block i 
: mnt sb 


: | mnt root | 


| d sb 
< | | dinode 


d name': / 


task struct 


fs struct (process 0) 


dentry(/) 


inode(/) 


i 
图 4-2 挂 载 rootfs 后 内 核 初始 虚拟 文件 系统 的 结构 
在 虚拟 文件 系统 中 ， 通 过 文件 系统 的 超级 块 、 文 件 系统 的 根 节点 ， 表 


加 上 文件 的 dentry， 束 可 以 在 虚拟 文件 系统 中 唯一 确定 文件 的 位 置 了 。 为 了 
程序 实现 上 的 方便 ， 内 核 中 设计 了 结构 体 vfsmount 和 path。vfsmount“ 封 


装 * 了 文件 系统 的 超级 块 、 文 件 系统 的 根 节点 等 。path“ 封 装 * 了 mount 和 


dentry ° 


事实 上 ， 虚 拟 文件 系统 这 棵 代表 整个 文件 系统 的 大 树 的 根 对 用 户 并 不 
可 见 ， 我 们 平时 在 进程 中 所 见 到 的 根 目 示 ， 仅 是 这 棵 树 上 的 一 个 分 文 而 
已 。 因 此 我 们 看 到 内 核 中 文件 系统 中 有 namespace 的 概念 ， 束 是 每 个 进程 都 
有 属于 目 己 的 文件 系统 空间 ， 现 实 中 多 数 进程 的 文件 系统 的 namespace 都 是 
相同 的 。 进 程 在 任务 结构 体 task_struct 中 的 fs_struct 中 记录 进程 的 文件 系统 的 
根 ， 也 就 是 进程 的 文件 系统 的 namespace，init_ mount_tree 调 用 set_fs_root 就 
是 这 个 目的 。 当 然 ， 此 时 的 current 指 向 的 是 内 核 的 原始 进程 ， 即 进程 0 。 


至 此 ， 通 过 挂 载 rootfs， 虚 拟 文件 系统 的 根 目 录 已 经 建立 起 来 ， 根 目录 
已 经 可 以 容纳 文件 了 。 所 以 ， 接 下 来 内 核 解压 initramfs 的 内 容 到 虚拟 文件 系 
统 的 根 中 ， 利 用 initramfs 中 的 内 容 挂 载 并 切换 到 真正 的 根 文件 系统 。 


4.2.2 ”解压 initramfs 到 rootfs 


在 挂 载 了 rootfs 后 ， 内 核 将 Bootloader 加 载 到 内 存 中 的 initramfs 中 的 文件 
解压 到 rootfs 中 。 而 这 些 文件 中 包含 了 驱动 以 及 挂 载 真正 的 根 文 件 系 统 的 工 
具 ， 内 核 通 过 加 载 这 些 驱 动 、 使 用 这 些 工 具 实 现 挂 载 真正 的 根 文 件 系 统 。 


一 旦 配置 内 核 文 持 initramfs， 那 么 内 核 将 编译 文件 initramfs.c， 脚 本 如 
下 所 示 : 


linux-3.7.4/init/Makefile 


Obj-$ (CONFIG BLK DEV_ INITRD) += initramfs.o 


而 在 文件 initramfs.c 中 ， 我 们 可 看 到 如 下 代码 : 


二 EnEESC 


rootfs initcall (populate rootfs), 


安 rootfs_initcall 告 诉 编译 器 将 函数 populate_rootfs 链 接 在 段 ".initcall" 部 
分 。 在 内 核 初始 化 时 ， 画 数 do_basic_setup 调 用 do_initcalls， 而 do_initcalls 执 
行 段 ".initcall" 中 包含 的 函数 ， 所 以 initramfs 在 此 时 被 解压 到 rootfs 中 。 


populate_rootfs 解 压 initramfs 的 代码 如 下 所 示 : 


linux=3.7.4/init/initramfs.,.c6 


static int init populate rootfs (void) 
char *err = Unpack to rootfs( initramfs start, \ 
initramfs size); 
if:. ‘(err) 
panic(err); /* Failed to decompress INTERNAL initramfs */ 
It (inttrad starkt) 
#ifdef CONFIG BLK DEV_ RAM 


#else 


printk (KERN INFO "Unpacking initramfs...\n') 
err = Unpack to rootfs((char *)initrd start, 
initrd engd w Lnitrd etart)y 
#endif 
} 
return 0; 


根据 populate_rootfs 的 代码 可 见 


1) populate_rootfs 首 先 调用 unpack_to_rootfs 将 内 核 内 置 的 initramfs 解 压 
到 rootfs 中 ; 


2) 接 下 来 ， 如 果 变 量 initrd_start 不 为 0， 那 么 说 明 还 有 一 个 外 部 的 
initramfs 通 过 Bootloader 加 载 了 ， 内 核 将 这 个 外 部 的 initramfs 也 释放 到 rootfs 
中 。 其 中 CONFIG_BLK_DEV_RAM 是 对 应 于 使 用 ramdisk 机 制 的 情况 ， 我 们 
不 关心 这 种 情况 。initrd_start 是 initramfs 被 加 载 到 内 存 中 的 起 始 位 置 。 
initramfs 通 党 作为 一 个 独立 的 外 部 文件 存在 ， 并 通过 Bootloader 加 载 到 内 
存 。 


事实 上 ， 内 核 也 允许 将 initramfs 和 内 核 映 像 构建 在 一 起 ， 统 一 通过 内 核 
加 载 ， 使 用 的 方法 是 : 首先 将 initramfs 的 内 容 保存 到 一 个 目录 ; 然后 将 这 个 


目录 指定 给 kbuild，kbuild 将 使 用 上 自 带 的 辅助 程序 gen_init_cpio 将 其 压缩 为 


initramfs; 最 后 链接 到 内 核 映像 的 段 ".init.ramfs" 中 。 这 种 方法 的 配置 方式 如 
图 4-3 所 示 。 


如 

*] Initial RAM filesystem and RAM disk (initramfs/initrd) support 
i initramfs) Initramfs source file(s) 

(0) User ID to map to © (user root) (NEW) 

(9) Group ID to map to © (group root) (NEW) 


Built-in initramfs compression mode (None) 
[ ] Optimize for size 


图 4-3 指定 initramfs 的 源 文件 所 在 目 承 


但 是 ， 即 使 我 们 没有 指定 将 initramfs 包 含 进 内 核 映像 中 ， 内 核 也 会 构建 


一 个 内 置 的 initramfs。 这 也 是 我 们 看 到 populate_rootfs 代 码 中 ， 第 一 个 
unpack_to_rootfs 是 无 条 件 执行 的 原因 。 


接 下 来 ， 我 们 束 具 体 看 看 这 个 内 置 的 initramfs 的 创建 过 程 。 


百 完 ， 内 核 的 链接 脚本 告诉 链接 器 将 段 ".init.ramfs" 中 包含 的 内 容 链 接 


到 内 核 映像 的 "Init code and data" 部 分 ， 链 接 脚本 如 下 所 示 : 


linux-3.7.4/arch/x86/kernel/vmlinux.lds.s 


SECTIONS 


{ 


/* Init code and data - will be freed after init */ 
. = ALIGN (PAGE SIZE); 
.init.begin : AT(ADDR(.init.begin) - LOAD OFFSET) { 
_ init begin = .; /* paired with init end */ 


} 


INIT DATA SECTION (16) 
/* freed after init ends here */ 
.init.end : AT(ADDR(.init.end) - LOAD OFFSET) { 


_init end = .; 


} 


在 ".init.begin" 和 ".init.end" 之 间 的 部 分 是 内 核 初始 化 时 使 用 的 代码 ， 在 
内 核 初始 化 完成 后 ， 将 再 无 用 处 ， 因 此 ， 内 核 初始 化 完成 后 ， 这 部 分 的 代 
码 将 被 释放 。 内 核 内 置 的 initramfs 束 被 包 含 在 这 里 。 我 们 先 来 看 一 下 宏 
INIT_DATA_SECTION 以 及 INIT_RAM_FS 的 定义 : 


linux-3.7.4/include/asm-generic/vmlinux.]lds.h 


#define INIT DATA SECTION (initsetup align) 
.init.data : AT(ADDR(.init.data) - LOAD OFFSET) { 
INIT DATA \ 
INIT SETUP (initsetup align) \ 


INIT CALLS \ 


CON INITCALL \ 


SECURITY INITCALL \ 
INIT RAM FS \ 
} 
#define INIT RAM FS \ 
. = ALIGN (4); \ 
VMLINUX SYMBOL( initramfs start) = .; _ 
*(.init.ramfs) 以 
. = ALIGN (8); \ 


{rit Fanfs. info} 


由 上 上 可见 ， 段 ".init.ramfs" 被 链接 到 了 内 核 映像 的 "Init code and data" 商 
分 ; 函数 unpack_to_rootfs 中 使 用 的 符号 _initramfs_start 指 回 段 ".initramfs" 的 


开头 。 
段 ".init.ramfs" 的 具体 内 容 在 文件 initramfs_data.S 中 ， 代 码 如 下 : 


Tirmnix-3.7.4/UsEy/ 1nitramfs data,.s 


, Section .init.ramfs, "a" 

Lrf gtart: 

.incbin _ stringify (INITRAMFS IMAGE) 
irf end: 

“Section .init.ramfs. info, "a" 

.Globl VMLINUX SYMBOL( initramfs size) 
VMLINUX SYMBOL( initramfs size): 


通过 伪 指 令 ".section.init.ramfs"， 链 接 器 将 initramfs 链 接 进 


段 ".init.ramfs"。 其 中 的 INITRAMFS_IMAGE 在 Makefile 中 定义 : 


linux-3.7.4/usr/Makefile 


AFLAGS initramfs data.o += \ 
-DINITRAMFS IMAGE="usr/initramfs data.cpios$ (suffix y)'" 


initramfs 可 以 采用 不 同 压缩 方式 ，suffix_y 是 对 应 的 后 缀 。 比 如 ， 如 有 果 
使 用 的 是 gzip 压 缩 方式 ， 则 后 缀 为 ".gz"; 如 果 使 用 的 是 bzip2 压 缩 方 式 ， 则 
后 组 是 ".bz2"; 等 等 。 当 然 也 可 以 不 必 压 缩 ， 因 为 内 核 最 终 会 被 压缩 。 


显然 ，initramfs_data.S 就 是 initramfs 的 内 容 (initramfs_data.cpio) 的 老 
装 。 另 外 在 这 个 文件 中 定义 了 代表 initramfs 大 小 的 符号 _initramfs_size， 这 


个 符号 也 是 函数 populate_rootfs 解 压 内 置 的 initramfs 时 需要 的 。 


接 下 来 ， 我 们 就 来 看 看 具体 的 initramfs 的 内 容 initramfs_data.cpio， 其 创 
建 规则 的 脚本 如 下 所 示 : 


linux-3.7.4/usr/Makefile 


$ (obj)/initramfs data.cpios$ (suffix y): $(obj)/gen init cpio \ 
$ (deps initramfs) klibcdirs 


$ (call if changed, initfs) 


关注 创建 initramfs_data.cpio 规 则 的 命令 ， 其 中 if_changed 这 个 表达 式 在 
讨论 内 核 的 构建 时 我 们 已 见 过 多 次 ， 其 核心 就 是 执行 命令 cmd_$1， 这 里 对 


应 的 惑 是 cmd_initfs， 该 命令 定义 如 下 : 


linux-3.7.4/usr/Makefile 


cmd initfs = $(initramfs) -o $@ $(ramfs-args) $ (ramfs-input) 


其 中 涉及 的 三 个 参数 的 定义 如 下 : 


linux-3.7.4/usr/Makefile 


initramfs = $(CONFIG SHELL) \ 
$ (srctree)/scripts/gen initramfs list.sh 
ramfs-input := \ 
$ (if $(filter-out "",$ (CONFIG INITRAMFS SOURCE)), \ 
$ (shell echo $ (CONFIG INITRAMFS SOURCE)),-d) 
ramfs-args := \ 
$ (if $ (CONFIG INITRAMFS ROOT UID), -u \ 
$ (CONFIG INITRAMFS ROOT UID)) \ 
$ (if $(CONFIG INITRAMFS ROOT GID), -g \ 
$ (CONFIG INITRAMFS ROOT GID)) 


其 中 : 
人 S initramfs 是 scripts 日 录 下 的 脚本 gen_initramfs_list.sh 。 


令 ramfs-input 指 定 了 创建 initramfs 的 输入 。 如 果 配 置 内 核 时 指定 了 构成 
initramfs 的 源 所 在 的 目录 ， 则 使 用 这 个 源 目录 下 的 文件 创建 initramfs; 否 
则 ， 只 传递 一 个 参数 "-d" 给 脚本 gen_initramfs_list.sh， 该 脚本 则 用 内 核 默认 
的 内 容 创建 initramfs。 


令 ramfs-args 这 个 参数 只 有 在 用 户 自己 指定 了 构建 initramfs 的 文件 时 才 
有 效 ， 默 认 是 "-u 0-g 0"， 是 告诉 内 核 将 这 些 文件 的 用 户 ID 和 组 ID 都 设置 为 


root ° 


综 上 所 述 ， 当 指定 了 initramfs 的 源 目 孙 时 ， 假 设 源 目 孙 
为 /vita/initramfs， 那 么 构建 initramfs 的 命令 展开 后 大 致 如 下 : 


scripts/gen initramfs list.sh -o usr/initramfs data.cpio \ 
-U 0 -g 0 /vita/initramfs 


脚本 gen_initramfs_list.sh 将 /vita/initramfs 目 录 下 的 文件 的 UID 和 GID 全 部 
设置 为 0， 即 root 用 户 和 组 的 ID， 然 后 将 日 录 下 的 内 容 打 包 为 


initramfs_data.cpio ° 


当 不 指定 initramfs 的 源 目 未 时 ， 创 建 内 置 的 initramfs 的 命令 展开 后 大 致 
如 下 : 


scripts/gen initramfs list.sh -o usr/initramfs data.cpio -da 


通过 命令 行 参数 "-d"， 即 "default initramfs"， 告 诉 脚 本 


gen_initramfs_list.sh 创 建 一 个 默认 的 initramfs， 其 包含 的 内 容 如 下 : 
linux-3.7.4/scripts/gen initramfs list.sh 


default initramfs() { 
cat <<-EOF >> ${output} 
# This is a very simple, default initramfs 


dir /dev 0755 0 0 
nod /dev/console 0600 0 0cS51 
di¥ /E60t O0700’ 0 
# fle /kinit var/kinit/kinlt 0755 0 0 
# nk /init kinit 0755 0 0 
EOF 


这 个 默认 的 initramfs 非 党 简单 ， 仅 包括 一 个 /dev 目 孙 ， 一 个 /dev/console 


设备 节点 以 及 一 个 /root 目 孙 。 


最 后 还 要 指出 的 一 点 是 ， 事 实 上， 即使 配置 内 核 不 支持 initramfs， 内 核 
在 内 部 依然 会 构建 一 个 最 小 的 initramfs。 根 据 init 目 录 下 的 Makefile， 当 配置 
内 核 不 支持 initramfs 时 ， 内 核 链 接 init 下 的 noinitramfs.c， 如 下 脚本 所 示 : 


linux-3.7.4/init/Makefile 
ifneq ($ (CONFIG BLK DEV_ INITRD),y) 


obj-y += noinitramfs.o 
else 


文件 noinitramfs.c 的 代码 如 下 : 


static int _ init default rootfs (void) 
{ 
int err; 
err = sys mkdir((const char user _ force *) "/dev", 0755); 
LE {err < 0) 
goto out; 
err = sys mknod((const char user _force *) "/dev/console", 


S IFCHR | S IRUSR | S_IWUSR, 
new_ encode dev (MKDEV(5, 1))); 
Lf (arr < D) 
goto out; 


err = sys mkdir((const char user _force *) "/root", 0700); 
i (err x 0) 
goto out; 


return 0; 


ouks 
printk (KERN WARNING "Failed to create a rootfs\n'"); 
return err; 


} 


rootfs initcall (default rootfs); 


由 代码 "rootfs_initcall(default_rootfs)" 可 见 ， 在 没有 配置 内 核 文 持 
initramfs 的 情况 下 ， 内 核 初 始 化 时 ， 依 然 会 执行 default_rootfs。 而 该 男 数 将 
在 rootfs 中 创建 /dev、Aroot 目 录 以 及 /dewconsole 节 点 。 


可 见 ， 无 论 在 什么 情况 下 ， 内 核 部 将 确保 有 一 个 initramfs。 那 么 内 核 为 
什么 要 这 么 做 呢 ? 因 为 第 一 个 进程 如 果 打 不 开 控 制 台 设备 


(dev/console) ， 那 么 其 将 异常 终止 ， 最 终 导致 内 核 panic。 所 以 ， 这 个 默 
认 的 initramfs 确 保 了 内 核 不 会 因为 第 一 个 进程 打 不 开 控制 台 设备 而 panic。 从 
某 种 意义 上 ， 也 可 以 将 其 看 作 内 核 虚 拟 文件 系统 的 一 个 Bootstrap ， 也 惑 是 
说 ， 如 果 没 人 给 内 核 提 供 一 个 最 小 的 文件 系统 的 内 容 ， 那 么 内 核 束 自 己 创 
建 二 人 


4.2.3” 挂 载 并 切换 到 真正 的 根 目录 


将 initramfs 成 功 解压 后 ， 挂 载 真 正 的 根 文 件 系 统 所 需 的 驱动 、 程 序 
等 已 经 全 部 俱 备 ， 可 以 挂 载 真正 的 根 文 件 系 统 了 。 假 设 真正 的 根 文件 
系统 在 第 一 块 硬 盘 的 第 一 个 分 区 ， 即 /dev/sdal1， 并 假设 挂 载 点 为 root， 
那么 挂 载 完 成 后 ， 文 件 系 统 的 目录 树 如 图 4-4 所 示 。 


mount1 | : mount2 | 


| | | 四 mnt_parent 
ivfsmount | ， : 


| mnt_mountpoint 
: mnt root | 


[EE 
| dentry(/) | 
Deaney 
1 本 | 


dentry(root) | | /dev/sdal : 


path | 
| | vfsmount | 


| mnt root ! 


dentry(/) 


1 rootfs 


fs _struct task_struct 


图 4-4 挂 载 根 文件 系统 后 虚拟 文件 系统 结构 


挂 载 真正 的 根 文 件 系统 ， 即 /devwsdal 时 ， 内 核 将 为 其 创建 一 个 
mount 对 象 ， 为 了 行文 方便 ， 这 里 用 mount2 指 代 。 为 了 方便 查找 ， 
mount2 会 被 内 核 加 入 到 一 个 Hash 表 中 。mount2 中 的 mnt_parent 指 向 了 代 
表 rootfs 的 mount1。mount2 中 的 mnt_mountpoint 指 向 该 文件 系统 的 挂 载 
点 ， 显 然 ， 这 里 是 rootfs 中 的 /root 目 录 。mount2 中 的 mnt_root 指 同人 代表 
根 文 件 系统 的 根 节 点 的 dentry 。 


此 时 ， 进 程 0 的 任务 结构 体 中 的 fs 的 root 和 pwd 均 指向 rootfs 的 根 节 
点 ， 当 然 ， 这 个 根 季 点 是 由 mount 和 rootfs 的 根 目录 的 dentry 的 共同 标识 
的 。 也 就 是 说 ， 此 时 进程 的 文件 系统 的 namespace 是 以 rootfs 的 根 目录 作 
为 根 的 目 隶 树 。 


挂 载 真 正 的 根 文 件 系统 后 ，rootfs 中 的 内 容 已 经 没有 保留 的 意义 ， 
但 是 并 不 能 将 rootfs 秋 载 ， 因 为 rootfs 是 整个 虚拟 文件 系统 的 根 。 因 此 ， 
为 了 不 占用 内 存 空间 ， 将 rootfs 中 的 内 容 (文件 ) 释放 掉 即 可 ， 然 后 将 
真正 的 根 文件 系统 移动 到 虚拟 文件 系统 的 根 〈 即 rootfs 的 根 ) 下 ， 最 后 
再 将 进程 的 文件 系统 的 namespace 切 换 到 真正 的 根 文件 系统 。 切 换 后 ， 
虚拟 文件 系统 中 的 相关 数据 结构 间 的 天 系 如 图 4-5 所 示 。 
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图 4-5 切换 根 目 孙 后 虚拟 文件 系统 结构 


4.3 配置 内 核 文 持 initramfs 


要 使 用 initramfs， 首 先 需 要 配置 内 核 支 持 initramfs， 配 置 步骤 如 
下 : 
1) 执行 make menuconfig， 出 现 如 图 4-6 所 示 的 界面 。 


LI 


Ef 


“- -> 用 


图 4-6 配置 内 核 支 持 initramfs (1) 
2) 在 图 4-6 中 选中 "General setup"， 出 现 如 图 4-7 所 示 的 界面 。 


HE 
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图 4-7 配置 内 核 支持 initramfs (2) 


) 在 图 4-7 中 选中 "Initial RAM filesystem and RAM 


disk(initramfs/initrd)support" 后 ， 在 该 选择 项 的 下 方 将 出 现 一 个 子 


项 "Initramfs source file(s)"。 可 以 在 这 里 指定 initramfs 所 在 的 目录 ， 内 核 
编译 时 ， 将 会 把 initramfs 所 在 的 目录 压缩 并 链接 到 内 核 的 一 个 特殊 的 数 
据 段 .initramfs 中 。 


当然 ， 我 们 也 可 以 不 将 initramfs 链 接 到 内 核 中 ， 而 是 将 其 作为 一 个 
单独 的 文件 ， 由 Bootloader 将 其 加 载 到 内 存 ， 而 这 也 是 通 冲 的 做 法 。 这 
时 ， 不 必 设 置 选项 "Initramfs source file(s)"。 


编译 文 持 initramfs 的 内 核 ， 并 将 其 保存 到 /vita/sysrootboot 目 孙 下 。 


4.4 构建 基本 的 initramfs 


在 这 一 节 ， 我 们 先 建立 一 个 initramfs 的 原型 ， 用 来 验证 内 核 配 置 以 及 这 
个 initramfs 原 型 。 我 们 在 /vita 目 录 下 创建 一 个 initramfs 目 录 ，initramfs 的 内 容 
保存 在 这 个 目录 中 。 


vita@baisheng:/vitas mkdir initramfs 


如 有 果 没 有 在 传递 给 内 核 的 命令 行 参 数 中 指定 "rdinit"， 内 核 启 动 后 ， 执 
行 的 initramfs 中 第 一 个 程序 是 根 目录 下 的 init。 那 我 们 就 从 创建 init 程 序 开 
始 ， 来 创建 我 们 的 initramfs。 


基本 上 所 有 的 init 程 序 都 是 采用 shell 脚 本 编写 的 ， 我 们 这 里 也 不 例外 ， 
当然 你 也 可 以 采用 其 他 语言 (比如 C) 来 编写 。 这 里 要 注意 的 一 点 是 ， 编 写 
init 脚 本 时 ， 用 来 指明 脚本 使 用 的 解释 器 的 字符 串 "#1/bin/bash" 一 定 要 从 第 一 
行 的 左 侧 第 一 个 字符 开始 ， 因 为 内 核 中 的 脚本 加 载 器 将 根据 脚本 文件 的 前 
两 个 字符 判断 使 用 什么 解释 器 。 具 体 如 下 : 


-vita/initramtsr linit 
#!/bin/bash 


echo "Hello Linux!" 
exec /bin/bash 


编写 完 这 个 脚本 后 ， 我 们 需要 为 其 增加 可 执行 属性 ， 具 体 如 下 : 


vita@baisheng:/vita/initramfss$s chmod a+x init 


这 个 脚本 首先 使 用 echo 输 出 "Hello Linux!"，echo 是 shell 内 置 的 命令 ， 不 
需要 再 额外 安装 其 他 程序 。 然 后 运行 一 个 交互 式 shell， 与 用 户 进行 交互 。 


shell 提 供 两 种 运行 模式 : 一 种 是 非 交 互 模式 ， 另 外 一 种 是 交互 模式 。 
在 运行 解释 init 脚 本 文件 时 ， 最 后 会 转化 为 形 如 "/bin/bash/init"， 即 将 脚本 文 
件 init 作 为 参数 传 给 bash 程 序 ， 这 是 典型 的 非 交 互 方式 ， 即 bash 的 输入 不 是 
通过 用 户 输入 ， 而 是 保存 在 一 个 shell 脚 本 文件 中 。 


但 是 ， 我 们 需要 通过 shell 与 内 核 进行 交互 ， 因 此 ， 最 后 通过 命令 启动 
了 一 个 新 的 shell， 这 个 bash 程 序 没有 任何 输入 ， 目 然 就 以 交互 模式 运行 ， 
为 其 需要 从 用 户 获 得 输入 。 这 里 使 用 exec 的 目的 是 后 面 的 shell 进 程 直接 代替 
前 面 的 shell 进 程 ， 而 不 是 复制 出 另外 一 个 进程 ， 也 就 是 确保 这 个 进程 依然 
是 pid 为 1 的 进程 。 


init 是 需要 shell 解 释 器 来 解释 运行 的 ， 因 此 ， 除 了 init 脚 本 文件 外 ， 
initramfs 中 还 需要 bash 程 序 。 安 装 bash 程 序 的 命令 如 下 : 


vita@baisheng:/vita/initramfs$ mkdir bin 
vita@baisheng:/vita/initramfs$ cp ../sysroot/bin/bash bin/ 


我 们 需要 检查 bash 依 赖 的 动态 库 ， 命 令 如 下 : 


vita@baisheng:/vita/initramfs$ ldd bin/bash 
libdl.so.2 => /vita/sysroot/lib/libdl.so.2 
libgcc s.so.1 =>/vita/cross-tool/i686-none-linux-gnu/ 
1i1b/libgee ‘sss0s:1 
libc.so.6 => /vita/sysroot/lib/libc.so.6 


bash 依 赖 于 libc、1libdl 以 及 libgcc_s.so.1， 因 此 ， 我 们 需要 在 initramfs 中 
安装 这 三 个 库 ， 以 及 安装 加 载 动 态 库 的 动态 加 载 /链接 器 。 安 装 命令 如 下 : 


vita@baisheng:/vita/initramfs$ mkdir lib 

vita@baisheng:/vita/initramfs$ cp -d /vita/sysroot/lib/libdl* \ 
LLB/ 

vita@baisheng:/vita/initramfs$ cp \ 
/vita/sysroot/lib/libc-2.15.so lib/ 

vita@baisheng:/vita/initramfs$ cp -d \ 
/vita/sysroot/lib/libc.so.6 lib/ 

vita@baisheng:/vita/initramfss$ cp \ 
/vita/cross-tool/i686-none-linux-gnu/lib/libgcc s.so.1 1Lib/ 

vita@baisheng:/vita/initramfs$ cp -d /vita/sysroot/lib/ld-* lib/ 


我 们 还 需要 检查 它们 的 依赖 。 


vita@baisheng:/vita/initramfs$ ldd 1ib/Lipbdal.so.2 
lBOrSow6 s> /vita/sVveroot /LID/LTibC.S0s6 
ld=l]inux.s0.2 ED /vita/syeroot/lib/l1d=1inux890.2 


vita@baisheng:/vita/initramfs$ ldd lib/libc.so.6 
1d-1inuX.B0s2 = /vita/Bveroot/lTipb/1d=11nux B02 


vita@baisheng:/vita/initramfs$ ldd lib/ld-linux.so.2 


vita@baisheng:/vita/initramfs$ ldd lib/libgcc s.so.1 
libousogne =» /vita/sveroot/ lib/libpe, so6 


根据 依赖 关系 可 见 ，libdl 依 赖 libc 和 动态 链接 器 ，libgcc 只 依赖 libc，libc 
仅 依 赖 动态 链接 器 ， 而 动态 链接 器 不 依赖 其 他 任何 库 ， 因 此 ， 我 们 不 再 需 
要 安装 其 他 库 到 initramfs 中 。 


至 此 ， 基 本 的 initramfs 已 经 准备 完成 ， 打 包 前 ， 我 们 可 以 使 用 find 命 令 
最 后 再 检查 一 遍 initramfs 中 的 内 容 : 


长 


vita@baisheng:/vita/initramfss$ find 


a 
Li LID BGa6 
了 es 
/LLiD/Lld=11inuxsBos2 
这 
LiD/L1ibDdl-2.15.B6 
LiD Ls L158 
LLL/TILDICG Bl 1 
st lIdt 

Din 

/bin/bash 


最 后 我 们 将 initramfs 打 包 并 压缩 ， 保 存在 /vita/sysroot/boot 目 录 下 。 根 据 
内 核 要 求 ， 需 要 使 用 cpio 压 缩 ， 并 且 压 缩 的 格式 为 "newc"， 上 有 具体 命令 如 下 : 


vita@baisheng:/vita/initramfs$ find . | cpio -o -H newc \ 
| gzip -9 > /vita/sysroot/boot/initrd.img 


我 们 将 bzImage 和 initrd.img 复 制 到 虚拟 机 .: 


vita@baisheng:/vita/sysroot/boots$ scp bzImage initrd.img \ 
root@192.168.56.101:/vita/boot/ 


然后 更 改 虚 拟 机 的 GRUB 的 配置 文件 grub.cfg， 告 知 GRUB 加 载 initrd 。 


menuentry 'vita' { 
Set roots" (Pa0 2 1 
linux /boot/bzImage root=/dev/sda2 ro 
Initrd /DOooE/Tnitrd: Lng 


重启 系统 ， 进 入 vita 系 统 ， 运 行 结 采 如 图 4-8 所 示 。 


11.10 [正在 运行 ] - Oracle VM VirtualBox 


Using IJPI Shortcut mode 
t: AT Translated Set 2 keyboard as /deuvuices/platform/i8042/serioQ/input/inpu 


.00:; ATAPI: VBOxX CD-ROM, 1.0, max UDMAx133 
.G0: conf igured for UPDMA/33 
3SATA link up 3.9 Ghbps (SStatus 123 3Control 300) 
.O90: PATA-6: VBOX HARDDISK, 1.0, max UDMA/133 
167772i6 sectors, multi i128: LBA48 NCQ tdepth 31732) 
: Conf igured for UpPMA/133 
:0:0: Direct-Access ATA UBOX HARDDISK 1.9 PQ: ©@ ANSI: 5 
:0: CD-ROM UBOX CD-ROM 1.9 pn: OhNSIL: 5 
[sda] 1b7?rzl6 Sie-byte logical blocks: (8.58 GB/8.00 GiB) 
[sda]l Write Protect is of 
[sda] Write cache: enabled, read cache: enabled, doesn’t support DPO 


sdae 
[sda] fttached SCSI disk 

reeing unused kernel memory: 348k freed 
ello Linuxt 

cannot set terminal process group (-1): Inappropriate ioct1l for device 

no job control in this shell 
bash-—4.2# tsc: Refined TSC clocksource calibration: 2380.841 MHz 
Switching to clocksource tsc 


bash—4,2# _ 


图 昌 多 男 国 全 多 图 右 ctrl 


图 4-8 运行 到 initramfs 中 的 bash 


由 图 4-8 可 见 ，initramfs 中 的 init 输 出 了 "Hello Linux!" 后 ， 启 动 了 一 个 交 
互 式 的 shell 。 


4.5 ”将 优盘 驱动 编译 为 模块 


initramfs 的 重要 作用 之 一 就 是 允许 内 核 将 保存 根 文 件 系统 的 存储 设备 的 
驱动 不 再 编译 进 内 核 。 上 一 厄 ， 我 们 体验 了 基本 的 initramfs， 这 一 节 ， 我 们 
束 将 硬盘 驱动 编译 为 模块 。 


4.5.1 配置 devtmpfs 


既然 提 到 设备 ， 而 且 Linux 将 设备 也 抽象 为 文件 ， 这 里 束 不 得 不 讨论 一 
下 设备 文件 或 者 说 设备 节点 。 通 常情 况 下 ， 某 些 需 要 从 用 户 空间 访问 的 设 
备 都 会 在 文件 系统 中 建立 一 个 设备 文件 ， 作 为 用 户 空间 访问 设备 的 接口 。 
得 益 于 Linux 中 虚拟 文件 系统 的 设计 ， 用 户 空 间 的 程序 可 以 像 访问 普通 文件 
一 样 ， 使 用 标准 的 文件 访问 接口 实现 与 设备 的 交互 。 


根据 FHS 的 规定 ， 设 备 文件 存放 在 /dev 目 未 下 。 在 Linux 系 统 的 早期 ， 
设备 文件 是 静 仿 创建 的 ， 所 有 的 设备 节点 十 手动 、 事 先 创建 的 。 笔 者 还 记 
得 在 早期 制作 Linux 发 行 版 时 ， 安 装 系 统 时 ， 需 要 静态 安装 大 量 的 设备 文 
件 ， 把 所 有 可 能 的 设备 入 点 一 并 创建 出 来 。 但 是 ， 这 样 市 来 的 一 个 问题 就 
古 ， 随 着 设备 的 种 类 越 来 越 多 ， 这 个 目录 会 越 来 越 大 ， 对 于 某 一 台 具 体 的 
机 器 来 说 ，dev 目 录 下 充 不 着 大 量 无 用 的 设备 文件 ， 因 为 某 些 设备 在 某 些 机 
右上 根本 就 不 存在 。 而 且 ， 这 种 方法 会 逐渐 耗 尽 设备 号 ， 昌 然 可 以 通过 扩 
展 设备 号 的 位 数 来 增加 设备 号 ， 但 终究 不 是 长 人 之 计 。 


鉴于 静态 创建 设备 文件 的 种 种 问题 ， 开 发 人 员 开 发 了 devfs。devfs 虽 然 
解决 了 按 需 创 建设 备 节 点 的 机 制 ， 但 是 还 是 有 很 多 问题 ， 比 如 设备 文件 的 
名 称 依然 由 驱动 开发 人 员 在 代码 中 指定 ， 而 不 能 由 系统 管理 员 指定 。 因 
此 ， 后 来 又 出 现 了 udev， 使 得 设备 命名 策略 、 权 限 控 制 等 都 在 用 户 空 间 完 
成 。 如 此 ， 设 备 文件 不 再 是 静态 创建 ， 而 是 由 udev 根 据 内 核 检 测 到 的 实际 
连接 的 设备 ， 创 建 相应 的 设备 文件 。 


对 于 动态 创建 设备 文件 ， 推 荐 在 /dev 目 录 下 挂 载 一 个 基于 内 存 的 文件 系 
统 。 基 于 内 存 的 文件 系统 会 完全 往 留 在 RAM 中 ， 读 写 可 以 瞬间 完成 。 除 了 
性 能 优势 之 外 ， 基 于 内 存 的 文件 系统 的 另外 一 个 特点 驳 是 没有 持久 性 ， 基 
于 内 存 的 文件 系统 中 的 数据 在 系统 重新 局 动 之 后 不 会 保留 。 这 看 起 来 可 能 
不 像 是 个 积极 因素 ， 然 而 ， 对 于 动态 创建 设备 节点 这 种 情况 来 说 ， 这 实际 
上 是 一 个 优势 。 在 系统 天 闭 后 ， 所 有 的 设备 节点 无 须 保留 ， 系 统 重启 后 ， 
udev 将 根据 内 核 检测 到 的 实际 设备 创建 设备 文件 。 


Linux 从 2.6.18 开 始 采 用 udev，/dev 目 录 使 用 了 基于 内 存 的 文件 系统 tmpfs 
管理 设备 文件 。 


2009 年 初 ， 开 发 人 员 又 提出 了 devtmpfs， 并 在 同年 年 底 被 Linux 2.6.32 正 
式 收录 。 内 核 引 导 时 ，devtmpfs 将 所 有 注册 的 设备 在 devtmpfs 中 建立 相应 的 
设备 文件 ， 一 旦 进入 用 户 空 间 ， 在 启动 udev 前 ， 就 可 以 将 devtmpfs 挂 载 
到 /dev 目 录 下 。 也 就 是 说 ， 在 启动 udev 前 ，devtmpfs 中 已 经 建立 了 初步 的 设 
备 文 件 ， 一 般 启 动 程序 不 必 再 等 待 udev 建 立 设备 节点 ， 甚 至 在 某 些 向 入 式 
系统 上 ， 不 再 需要 udev 创 建设 备 节 点 ， 因 为 这 个 基本 的 /dev 已 经 足够 ， 从 而 


缩短 了 系统 的 启动 时 间 。 同 rootfs 类 似 ，devtmpfs 也 不 是 新 设计 的 文件 系 
统 ， 如 果 内 核 配 置 支持 tmpfs， 那 么 其 束 是 tmpfs; 否则 ，devtmpfs 驶 是 
ramfs， 只 不 过 换 了 一 个 名 字 而 已 。 


下 面 我 们 就 实际 体验 一 下 devtmpfs。 为 此 ， 我 们 需要 在 initramfs 中 安装 
工具 ls 和 mount 。 


工具 ls 在 coreutils 中 ， 所 以 首先 编译 安装 coreutils: 


vita@baisheng:/vita/builds$ tar \ 
XVvf ../source/coreutils-8.20.tar.xz 
vita@baisheng:/vita/build/coreutils-8.20$ ./configure \ 
--prefix=/usr 
vita@baisheng:/vita/build/coreutils-8.20$ make install 


下 面 使 用 ldd 检 查 1s 依 赖 的 库 : 


vita@baisheng:/vitas ldd sysroot/usr/bin/ls 
librt.so.1 => /vita/sysroot/lib/librt.so.1 
libgcm BaaGal, ES 
/vita/cross-tool/i686-none-linux-gnu/lib/libgcce s.so.1 
liDe. SOL. =» /vita/sysroot/ libylibesso6 


vita@baisheng:/vitas ldd sysroot/lib/librt.so.1 
libc.so.6 => /vita/sysroot/lib/libc.so.6 
libpthread.so.0 => /vita/sysroot/lib/libpthread.so.0 
ld-linur aon2 SS /vita/sveroot/LTLiD/LId- nx S02 


vita@baisheng:/vitas ldd sysroot/lib/libpthread.so.0 
libDesBose = /Vita/syvaroot /Tib/Tibessos6 
ld-linux.so.2 => /vita/sysroot/lib/ld-linux.so.2 


根据 ldd 的 输出 可 见 ，ls 依 赖 的 库 除了 librt 和 libpthread 尚 未 安装 到 
initramfs 中 外 ， 其 余 已 经 安装 ， 所 以 我 们 将 ls 以 及 librt 和 1libpthread 复 制 到 


initramfs 中 : 


vita@baisheng:/vitas$ cp sysroot/usr/bin/ls initramfs/bin/ 
vita@baisheng:/vitas$ cp -d sysroot/lib/librt* initramfs/lib/ 
vita@baisheng:/vitas$ cp -d sysroot/lib/libpthread* initramfs/l1ib/ 


工具 mount 在 软件 包 util-linux 中 ， 我 们 首先 来 编译 这 个 软件 包 : 


vita@baisheng:/vita/builds$ tar xvf \ 
../source/util-linux-2.22.tar.xz 
vita@baisheng:/vita/build/util-linux-2.22$ ./configure \ 
--prefix=/usr --disable-use-tty-group --disable-login \ 
--disable-sulogin --disable-su --without-ncurses 
vita@baisheng:/vita/build/util-linux-2.22$ make 
vita@baisheng:/vita/build/util-linux-2.22$ make install 
vita@baisheng:/vita/build/util-linux-2.22$ find $SYSROOT \ 
-name "*.]a" -exec rm -f '{}' \; 


下 面 使 用 ldd 检 查 mount 依 赖 的 库 : 


vita@baisheng:/vitas$ ldd sysroot/bin/mount 
lipmount.Bo,.1 ss /vita/sysroot/lib/libmount.so.,.1 
1ibblkid:B6.1 = /vita/sveroot/1ib/1ibB1kid.s601 
libuuid.so.1 => /vita/sysroot/lib/libuuid.so.1 
lBowBo6 a /Vita/ vio /LIB/LIbDGed6E 


vita@baisheng:/vitas$ ldd sysroot/lib/libmount.so.1 
1ibblkidasol = /vita/syBroot/lib/lLibpblkidsso.1 
lBUUlid .B00.1 SS /vita/Bvaroot/LlTibp/libuiid.so,1 
l1iBbe80.6 =» /vita/sysroot/lib/libessose 


vita@baisheng:/vitas$ ldd sysroot/lib/libblkid.so.1 
libuuid.so.1 => /vita/sysroot/lib/libuuid.so.1 
1iDGaBOne =5 /Tifa/aveEoot/lLiD/ALIDEedo6 


vita@baisheng:/vitas ldd sysroot/lib/libuuid.so.1 
libe.80.6 = /vita/sysroot/lib/libc sos6 


根据 ldd 的 输出 可 见 ，mount 依 赖 libmount、1libblkid、1libuuid 以 及 libc 。 
libc 已 经 安装 到 了 initramfs 中 ， 我 们 将 mount 和 其 余 几 个 库 复 制 到 initramtfs: 


vita@baisheng:/vitas cp sysroot/bin/mount initramfs/bin/ 
vita@baisheng:/vitas$ cp -d sysroot/lib/libmount.so.1* \ 


initramfs/1ib/ 

vita@baisheng:/vitas$ cp -d sysroot/lib/libblkid.so.1* \ 
initramfs/lib/ 

vita@baisheng:/vitas$ cp -d sysroot/lib/libuuid.so.1* \ 
initramfs/1lib/ 


重新 压缩 initramfs， 并 将 其 保存 到 /vita/sysroot/boot/ 目 录 下 。 接 下 来 ， 
我 们 准备 支持 devtmpfs 的 内 核 ， 配 置 步 又 如 下 : 


1) 执行 make menuconfig， 出 现 如 图 4-9 所 示 的 界面 。 


= DFKLnO SU Rf, aa 


oe 


vice Drivers --->| 


" 
lo dl Fe 


图 4-9 配置 内 核 支 持 devtmpfs (1) 


2) 在 图 4-9 中 ， 选 择 "Device Drivers"， 出 现 如 图 4-10 所 示 的 界面 。 


图 4-10 ”配置 内 核 支持 devtmpfs (2) 


3) 在 图 4-10 中 ， 选 择 "Generic Driver Options"， 出 现 如 图 4-11 所 示 的 界 
面 O 


ath to Uevent hel 
Maintain a devtmpfs filesystem to mount at 


Automount devtmpfs at /dev, after the kernel 
Prevent firmware from being built 
Userspace firmware loading support 


图 4-11 配置 内 核 支 持 devtmpfs (3) 
4) 在 图 4-11 中 ， 选 中 "Maintain a devtmpfs filesystem to mount at/dev" 。 


编译 内 核 ， 并 将 内 核 与 前 面 准 备 好 的 initramfs 复 制 到 虚拟 机 的 目标 系统 
上 ， 然 后 重启 进入 vita 系 统 。 使 用 ls 列 出 vita 系 统 /dev 下 的 设备 文件 ， 如 图 4- 
12 所 示 。 


11.10 [正在 运行 ] - Oracle VM VirtualBox 


.00: ATAPI: UBOX CD-ROM, 1.0, max UDMA/133 
0 for UDMh“-33 
: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 
.O00: ATA-6: UBOX HARDDISK, 1.0, max UDMA/133 
.QO0: 16777?216 sectors, multi 128: LBA48 NCQ (depth 31/32) 
.OO0: conf igured for UDPMA/133 
i 9: 0:0:0: Direct-Access ATA UBOxX HARDDISK 1.0 PPO: © ANSI: 5 
i :0:0:; CD-ROM UBOX CD-ROM 1.0 PQ: © ANSI: 5 
:0: [sda] 167?7?7?216 512-bute logical blocks: (8.58 GB/8.00 GiB) 
:O: [sda] Write Protect is off 
:0; [sda] Write cache: enabled, read cache: enabled, doesn’t support DPO 


: sdal sdaz 


; [sda] fttached SCSI disk 

Freeing unused kernel memory: 348k freed 

Hello Linuxt? 

bash: cannot set terminal process group (-1): Inappropriate ioct1l for device 
bash: no job control in this shell 

bash-4.2z# tsc: Refined TSC clocksource calibration: 2Z385 .4493 MHz 

switching to clocksource tsc 


鲜 吕 四 上 自 OBOcr 


图 4-12 未 挂 载 任 何 文件 系统 的 /dev 目 孙 


根据 图 4-12 可 见 ，/dev 目 孙 下 包含 一 个 设备 节点 console。 但 是 我 们 的 
initramfs 中 并 没有 包含 这 个 设备 节点 ， 那 么 这 个 设备 节点 是 谁 创 建 的 呢 ? 大 
家 一 定 还 记得 我 们 前 面 讨论 过 的 内 置 的 initramfs 吧 ? 没 错 ， 这 个 console 职 是 


由 内 置 的 initramfs 创 建 的 。 
接 下 来 我 们 使 用 下 面 的 命令 将 ramfs 挂 载 到 /dev 目 录 下 。 
mount -n -t ramfs none /aev 


因为 ramfs 只 是 一 个 基于 内 存 的 文件 系统 ， 与 设备 无 关 ， 所 以 mount 命 令 
中 的 "device" 参 数 可 以 使 用 任意 字 串 描述 。 习 惯 上 ， 对 于 这 类 没有 具体 设备 
的 ， 一 般 使 用 字 串 "none" 表 示 。 但 是 mount 命 令 不 推荐 这 样 使 用 ， 因 为 在 某 
些 情况 下 ， 某 些 提示 很 容易 让 用 户 费 解 ， 比 如 "mount: none already 
mounted"。 这 里 我 们 暂时 使 用 "none"， 在 最 终 系统 中 我 们 使 用 "udev"， 表 示 
该 目录 下 的 节点 是 由 udev 创 建 的 。 默 认 情 况 下 ，mount 命 令 会 在 文 
件 /etcmtab 中 维护 一 份 当前 已 挂 载 的 文件 系统 列表 ， 因 为 我 们 的 initramfs 中 
没有 创建 /etcmtab 文 件 ，initramfs 中 也 不 需要 ， 因 此 使 用 参数 "-n" 告 诉 mount 
不 需 维护 这 份 列表 。 


挂 载 完 成 后 ， 我 们 查看 /dev 下 的 设备 文件 。 情 况 非 常 糟糕 ，/dev 下 挂 载 
了 一 个 空 的 ramfs 文 件 系统 ， 原 有 的 console 设 备 节 点 也 被 覆盖 了 ， 如 图 4-13 
所 示 。 


11.10 [正在 运行 ] - Oracle VM VirtualBox 


.90: conf igured for UDMA/33 
SATA link up 3.0 Gbps (SStatus i123 SControl 300) 
Pe Ss 
: 16777216 sectors, multi 128: LBA48 NCQ (depth 31/32) 
: conf igured for UDMA/133 
:0:0; Direct-hccess 和 IT 全 UBOX HARDDISK 1.0 PQ: © ANSI;: 5 
:0: CD-ROM UBOX CD-ROM 上 .9 PU: Q@ ANST: 5 
[sda] 167?7?7?7216 Siz-byte logical blocks: (8.58 GB/8.00 GiB) 
[sda] Write Protect is off 
[sda] Write cache: enabled，read cache: enabled，doesn't suppbort DP0 


[sda] httached SCSI disk 
Freeing unused kernel memory: 348k freed 
Hello Linux? 
bash: cannot set terminal process group (-1): Inappropriate ioct1l for duewice 
no job control in this shell 
-4.2# tsc: Refined TSC clocksource calibration: 2385 .443 MHz 
Switching to clocksource tsc 


bash-4.z# 1s xdueu 

onsole 

bash-4.2# mount -nm -t ramfs none /dev 
hash-4.z# 1s xdueuw 

LE me .2 站 
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图 4-13 挂 载 ramfs 文 件 系统 的 /dev 目 录 


接 下 来 我 们 使 用 下 面 的 命令 将 devtmpfs 挂 载 到 /dev 目 未 下 : 


mount -n -t devtmpfs none /dev 


挂 载 完 成 后 ， 我 们 再 次 查看 /dev 下 的 设备 文件 。 可 以 看 到 ，devtmpfs 下 


面 已 经 建立 了 若干 设备 六 点 ， 如 图 4-14 所 示 。 
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Freeing unused kernel memory: 
Hello Linuxt 
bash: cannot set terminal process group (-1) ， 
bash: no job control in this shell 

bash-4.2# 七 scC: Refined TSC clocksource calibration : 
Switching to clocksource tsc 


ls dev 


348k freed 


mount -nm -t ramfs none /dev 


ls dev 


mount -nm -t devtmpfs none /dev 


ls dev 
random 
sda 
sdal 
sdaz 
ttyu 
ttuQ 
network_latency ttuyul 
network_throughput tty1i0 
tty1i1 
ttuyulilz 
tty1i3 


ttuyul4 
tftU15 
ttyi6 
tty1i7? 
ttuU18 
tty19 
ttyuz 

ttUZO 
ttyz1 
ttyze 
ttyz3 


ttU24 
ttUc5 
ttyz6 
ttUZ7 
ttUz8 
ttU29 
tty3 

ttuU30 
tty31 
ttU32 
tty33 


Inappropriate ioct1l for device 


Z385449MHNz 


ttyu? 

tty8 

ttyu9 
urandom 

UCS 

vcCSs1 

UCSA 

vcsal 
vya_arbiter 
Zero 


OPPAN OD 


图 4-14 挂 载 devtmpfs 后 的 /dev 目 了 


既然 devtmpfs 有 这 么 多 的 好 处 ，/dev 目 录 当 然 要 使 用 devtmpfs 文 件 系 统 
了 。 因 此 ， 按 照 下 面 的 脚本 修改 initramfs 中 的 init 文 件 : 


/WL LamEsinit 


#!/bin/bash 


echo "Hello Linux!" 


mount -n -t devtmpfs udev /dev 
exec /bin/bash 


4.5.2 ”将 硬盘 控制 絮 驱 动 配置 为 模块 


与 前 面 配 置 硬盘 控制 妖 驱 动 类 似 ， 只 不 过 这 里 我 们 将 "AHCI SATA 
support" 和 "Intel ESB,ICH,PIIX3,PIIX4 PATA/SATA support" 配 置 为 模块 ， 如 
图 4-15 所 示 。 


AHCI SATA support 

Platform AHCI SATA Support 

Initio 162x SATA sypport 

ACard AHCI variant (ATP 8626) 

silicon Image 3124/3132 SATA syupport 

ATA SFF support (for legacy IDE and PATA) 


*x* SFF controllers with custom DMA interface ** 
Pacific Digital ADMA support 
Pacific Digital SATA QStor support 
ATA BMDMA support 
去 SATA SFF controllers with BMDMA 六 六 大 
Intel ESB, ICH, PILIX3, PIIX4 PATA/SATA suyupport 


图 4-15 ”配置 SATA 控 制 器 驱动 为 模块 


接 下 来 重新 编译 内 核 和 模块 。 内 核 和 模块 可 以 使 用 单独 的 命令 分 开 编 
译 ， 也 可 以 使 用 一 条 make 命 令 同时 编译 内 核 和 模块 。 编 译 完 成 后 ， 将 模块 
暂时 安装 在 "/vita/sysrooUlib/modules" 目 录 下 。 
vita@baisheng:/vita/build/linux-3.7.4$ make bzImage 
vita@baisheng:/vita/build/linux-3.7.4$ make modules 


vita@baisheng:/vita/build/linux-3.7.4$ make \ 
INSTALL MOD PATH= SSYSROOT modul es_instal 1 


终 安装 的 硬 副 控制 器 驱动 模块 包括 : 


vita@baisheng:/vitas$ ls \ 
sysroot/lib/modules/3.7.4/kernel/drivers/ata/ 
ahedlske ata pliixsko libahcisko 


我 们 将 其 复制 到 initramfs 中 。 


vita@baisheng:/vitas mkdir -p \ 
initramfs/lib/modules/3.7.4/kernel/drivers/ata 

vita@baisheng:/vitas cp \ 
sysroot/lib/modules/3.7.4/kernel/drivers/ata/* \ 
initramfs/lib/modules/3.7.4/kernel/drivers/ata/ 


为 了 加 载 内 核 模 块 ， 我 们 需要 安装 加 载 、 和 扼 载 等 管理 模块 的 工具 ， 这 
些 工 具 在 包 kmod 中 : 


vita@baisheng:/vita/builds tar xvf ../source/kmod-12.tar.xz 
vita@baisheng:/vita/build/kmod-12$ ./configure --prefix=/usr 
vita@baisheng:/vita/build/kmod-12$ make 
vita@baisheng:/vita/build/kmod-12$ make install 
vita@baisheng:/vita/build/kmod-12$ find $SYSROOT \\ 

-name "*.]la" -exec rm -f '{}' \; 


检查 kmod 的 依赖 : 


vita@baisheng:/vitas$ ldd sysroot/usr/bin/kmod 
libkmod.so.2 => /vita/sysroot/usr/lib/libkmod.so.2 
libc.so.6 => /vita/sysroot/lib/libc.so.6 


vita@baisheng:/vitas ldd sysroot/usr/lib/libkmod.so.2 
Iiben soe Es /vitarsv earoot /LlibB/lLibDeadse 


根据 和 输出 可 见 ，kmod 及 库 libkmod 只 依赖 libc 库 ， 而 libc 已 经 安装 到 
initramfs， 所 以 复制 kmod 及 库 libkmod 到 initramfs 即 可 ， 上 有 具 体 如 下 : 


vita@baisheng:/vita/initramfs$ mkdir usr/bin 

vita@baisheng:/vitas$ cp sysroot/usr/bin/kmod initramfs/usr/bin/ 

vita@baisheng:/vitas$ cp -d sysroot/usr/lib/libkmod.so.2* \ 

initramfs/l1ib/ 
kmod 是 module-init-tools 的 替代 者 ， 但 是 kmod 是 回 后 兼容 module-init- 

tools 的 ， 虽 然 kmod 只 提供 一 个 工具 kmod， 但 是 通过 符号 链接 的 形式 支持 
module-init-tools 中 的 各 个 命令 ， 而 且 目 前 来 看 ， 也 只 能 使 用 这 种 方式 来 使 
用 各 种 模块 管理 命令 。 因 此 ， 需 要 为 各 个 模块 管理 命令 建立 符号 链接 ， 并 
将 这 些 符号 链接 也 复制 到 initramfs 中 : 


vita@baisheng:/vita/sysroot/sbins$ ln -s ../usr/bin/kmod insmod 
vita@baisheng:/vita/sysroot/sbins$ ln -s ../usr/bin/kmod rmmod 
vita@baisheng:/vita/sysroot/sbins$ ln -s ../usr/bin/kmod modinfo 
vita@baisheng:/vita/sysroot/sbin$ ln -s ../usr/bin/kmod lsmod 
vita@baisheng:/vita/sysroot/sbins$ ln -s ../usr/bin/kmod modprobe 


vita@baisheng:/vita/sysroot/sbins$ ln -s ../usr/bin/kmod depmod 
vita@baisheng:/vitas$ mkdir initramfs/sbin 


vita@baisheng:/vita/sysroot/sbins$ cp -d insmod rmmod \ 
modinfo lsmod modprobe depmod /vita/initramfs/sbin/ 


其 中 ，insmod、rmmod、modprobe 用 于 加 载 / 缉 载 模 块 ，modinfo 用 于 查 
看 模块 信息 lsmod 用 于 查看 已 经 加 载 的 模块 ，depmod 用 于 创建 模块 间 的 依 
赖 关系 。 注 意 ， 这 里 一 定 要 将 modprobe 等 命令 放 在 /sbin 目 录 下 ， 因 为 后 面 
的 udevd 将 会 到 使 用 "/sbin/modprobe" 的 形式 调用 modprobe 命 令 。 最 新 的 合并 
到 systemd 中 的 udev 不 再 直接 调用 modprobe 等 工具 ， 而 是 使 用 libkmod 提 供 的 
库 提供 的 API 加 载 模块 ， 但 并 无 本 质 区 别 。 


bash 的 默认 搜索 命令 的 路 径 为 /usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:. 
我 们 当然 可 以 使 用 全 路 径 运 行 命令 ， 比 如 /sbinm/insmod， 但 是 为 了 方便 ， 我 


们 还 是 在 init 脚 本 中 对 搜索 命令 的 路 径 进行 一 些 调整 。bash 中 ， 保 存 搜索 命 
令 的 环境 变量 为 PATH 


#!/bin/bash 

echo "Hello Linux!" 

export PATH=/usr/sbin:/usr/bin:/sbin:/bin 
mount -n -t devtmpfs udev /dev 

exec /bin/bash 


压缩 initramfs， 并 将 其 和 不 包含 硬盘 张 动 的 bzImage 复 制 到 虚拟 机 ， 然 
后 重 局 系统 。 进 入 系统 后 ， 因 为 内 核 中 已 经 没有 便 盘 控制 器 的 续 动 ， 所 以 
在 /dev 目 孙 下 不 会 有 类 似 /devsdaX 的 设备 万 点 。 为 了 识别 硬 列 ， 我 们 需要 加 
载 便 开 控制 邵 的 驱动 。 


前 面 提 到 ，Intel 的 SATA 控 制 妖 可 以 运行 在 Compatibility 模 式 和 AHCI 模 
式 。 笔 者 的 机 器 的 SATA 控 制 器 工作 在 AHCI 模 式 ， 因 此 使 用 ahci 驱 动 。 但 是 
在 试图 加 载 ahci 模 块 时 ，ahci 模 块 在 报告 了 阁 干 找 不 到 的 符号 后 ， 加 载 以 失 
败 告终 ， 如 图 4-16 所 示 。 


11.10 [正在 运行 ] - Oracle VM VirtualBox 


bash: cannot set terminal process group (-1): Inappropriate ioct1l for device 
bash: no job control 
Ref ined TSC clocksource calibration: 2380 ,898 MHz 


LT Lis 4 Wh :HD 


in this shell 


Switching to clocksource tsc 


-4.2# insmod /lib/modules/3.7?7.4/kernel/drivers/ata/ahci.ko 


i: Unknown 
i: Unknown 
: Unknown 
i: Unknown 
i: Unknown 
: Unknown 
i: Unknown 
i: Unknown 
i: Unknown 
i: Unknown 
i: Unknown 
i: Unknown 
i: Unknown 
i: Unknown 
i: Unknown 
i: Unknown 


insmod: ERROR: 


i.ko: Unknown 
bash-4.2Z# _ 


symbol 
symbol 
symbol 
symbol 
symbol 
symbol 
symbol 
symbol 
symbol 
symbol 
symbol 
symbol 
symbol 
symbol 
sUmhbol 
symbol 

could 
symbol 


ahci_ops (err 0) 
ahci_start_engine (err 0) 
ahci_interrupt (err 0) 
ahci_check_ready (err 0) 
ahci_kick_engine (err 0) 
ahci_set em messages (err 0) 
ahci_init_controller (err 0) 
ahci_shost attrs (err 0) 
ahci_reset_controller (err ©) 
ahci_ print_info (err 0) 
ahci_stop_engdgine (err OO) 
ahcioreset em (err 0d) 

ahci_sdew attrs (err QO) 

ahci pmp_retry_srst_ ops (err QO) 
ahci_save_initial_conf ig (err 0) 
ahci_ignore_sss (err 0) 

not insert module /lib/modules/3.7.4/kernel/drivers/ata/ahc 
in module 


OFAN OBicr | 


显然 


图 4-16 加 载 ahci 模 块 失败 


然 ， 这 些 找 不 到 的 符号 应 该 定义 在 其 他 某 个 〈 些 ) 未 加 载 的 模块 


中 ， 我 们 需要 使 用 命令 modinfo 查 看 一 下 模块 ahci 依 赖 了 哪些 模块 ， 我 们 使 
用 参数 "-F depends" 人 告诉 modinfo 仪 显示 ahci 的 依赖 信息 .: 


vita@baisheng:/vitas$ modinfo -F depends \ 
sysroot/lib/modules/3.7.4/kernel/drivers/ata/ahci .ko 


lipbahci 


根据 modinfo 的 输出 ， 我 们 可 以 看 到 ，ahci 模 块 依赖 libahci 模 块 。 因 此 ， 
我 们 首先 需要 加 载 libahci 模 块 ， 然 后 再 加 载 ahci 模 块 ， 如 图 4-17 所 示 。 
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bash: no job control in this shell 
bash-4.2# tsc: Refined TSC clocksource calibration: 2382 .351 MHz 
Switching to clocksource tsc 


bash-4.2# insmod TT a A Pd pd i 4 
bash-4.2# insmod /lib/modules/3.7?.4/kernel/drivers/ata/ahci ,ko 
ahci: sss3 flag set, parallel bus scan disabled 
ahci O000:00:04.0: AHCI 0001.01060 32 slots 1 ports 3 Gbps Oxi1 impl SATA mode 
ahci 9000:00:0d.0:; flags: 64bit mcd stag only ccc 
i : ahci 
: SATA max UDMA/133 abar m819Z@0Oxf0806000 port QOQxf 0806100 irg Zz1 
: SATA link up 3.0 Gbps (SStatus 123 sControl 300) 
.O00: ATA-6: UBOX HARDDISK, 1.0, max UDMA/133 
.O00: 16777216 sectors, multi 128: LBA48 NCQ (depth 31/32) 
: conf igured for UDMAx133 
:0:0:0: Direct-ficcess ATA UBOX HARDDISK 1.0 PQ: © ANSI: 5 
:0:0: [sdua] 1677?7?216 Siz-byte logical blocks: (8.58 GB/8.00 GiB) 
:0:0: [sda] Write Protect is off 
:9: [sda] Write cache: enabled, read cache: enabled, doesn’t support DPO 


sda: sdal sdaz 
sd OQ:0:0:0: [sda] fttached SCSI disk 
bash-4.2# ls dev/sdax 
/dev/sda -dew/sdal dev/sdaz 
LR Ls 4 


DD) 户 要 国信 | 多 团 右 ctrl 


图 4-17 ”加载 ahci 模 块 成 功 


加 载 ahci 模 块 后 ， 该 模块 正确 识别 出 了 硬盘 控制 器 ， 并 且 内 核 在 
devtmpfs 中 也 建立 了 对 应 硬盘 的 设备 节点 。 


虽然 使 用 insmod 可 以 完成 加 载 模块 的 功能 ， 但 是 我 们 发 现 必 须要 对 模 
块 的 依赖 关系 非常 清楚 。 幸 运 的 是 ahci 只 依赖 libahci， 而 且 libahci 不 依赖 其 
他 模块 。 但 是 如 采 一 个 模块 依赖 多 个 模块 ， 并 且 依 赖 的 模块 又 依 赖 其 他 的 
模块 ， 如 此 下 去 ， 可 想 而 知 ， 加 载 这 样 一 个 模块 将 是 多 么 复杂 。 好 在 kmod 
中 提供 了 另外 一 个 加 载 /外 载 模块 的 工具 modprobe， 与 insmod 和 rmmod 相 
比 ，modprobe 可 以 目 动 加 载 / 凶 载 模块 依赖 的 其 他 模块 ， 而 模块 间 的 依赖 天 
系 存 储 在 modules 目 了 永 下 的 modules.dep 中 。 以 硬盘 张 动 这 几 个 模块 为 例 ， 其 
在 modules.dep 中 的 内 容 如 下 : 


kernel/drivers/ata/ahci.ko: kernel/drivers/ata/libahci .ko 
kernel/drivers/ata/libahci .ko: 
kernel/drivers/ata/ata piix.ko: 


该 片段 表示 模块 ahci.ko 依 赖 libahci.ko， 而 模块 libahci.ko 和 ata_piix.ko 不 
依赖 其 他 模块 。 


如 果 模 块 间 依赖 关系 简单 也 罢 ， 但 是 如 果 比 较 复 杂 ， 那 么 手动 去 创建 
modules.dep 是 不 现实 的 ， 邓 运 的 是 ， 模 块 管理 工具 中 也 提供 了 相应 的 工具 
创建 modules.dep 文 件 ， 这 个 工具 束 是 depmod。 在 安装 内 核 模块 时 ， 安 装 脚 
本 将 目 动 调用 这 个 工具 ， 创 建 modules.dep 等 文件 。 


为 了 加 快 搜索 过 程 ，modules.dep 通 党 使 用 更 有 效率 的 Trie 树 来 组 织 ， 并 
命名 为 modules.dep.bin。module-init-tools 中 实现 的 modprobe 上 述 两 种 格式 都 
支持 ， 当 然 首选 使 用 modules.dep.bin。 但 是 kmod 仅 支持 使 用 Trie 树 形式 存储 
的 modules.dep.bin 。 


接 下 来 我 们 就 体验 一 下 使 用 modprobe 加 载 驱 动 模块 。 首 先 需 要 创建 模 
块 依赖 关系 文件 。 一 般 而 言 ， 对 于 通用 系统 ， 通 常 在 安装 系统 时 使 用 
depmod 创 建 依赖 天 系 文件 ， 然 后 如 果 模 块 有 变动 ， 可 以 使 用 depmod 命 令 更 
注 这 时 文件 % 


在 这 里 ， 在 安装 内 核 模 块 时 ， 安 装 脚本 已 经 调用 depmod 创 建 了 
modules.dep 和 使 用 Trie 树 组 织 的 modules.dep.bin， 注 意 需 要 将 使 用 Trie 树 组 
织 的 modules.dep.bin 复 制 到 initramfs。 当 然 ， 如 果 使 用 了 module-initrtools 中 
的 模块 管理 工具 ， 那 么 这 里 完全 可 以 体验 一 下 手写 modules.dep 文 件 。 


vita@baisheng:/vitas$ cp \ 
sysroot/lib/modules/3.7.4/modules.dep.bin \ 
initramfs/lib/modules/3.7.4/ 


为 了 验证 modprobe 是 否 正 确 加载 了 模块 ， 可 以 使 用 命令 lsmod 查 看 内 核 
加 载 的 模块 。 但 是 lsmod 是 通过 proc 和 sysfs 获 取 内 核 信息 的 ， 因 此 ， 为 了 使 
用 lsmod， 首 先 需要 挂 载 proc 和 sysfs 文 件 系统 。 为 此 ， 我 们 需要 在 initramfs 的 
根 目录 下 创建 proc 和 sys 目 录 作 为 挂 载 点 : 


vita@baisheng:/vita/initramfs$ mkdir proc sys 
同时 修改 init 脚 本 ， 添 加 挂 载 proc 和 sysfs 文 件 系 统 的 脚本 : 


#!/bin/bash 

echo "Hello Linux!" 

export PATH=/usr/sbin:/usr/bin:/sbin:/bin 
mount -n -t devtmpfs udev /dev 

mount -n -t proc proc /proc 

mount -n -t sysfs sysfs /sys 

exec /bin/bash 


重新 压缩 initramfs， 并 将 其 复制 到 虚拟 机 ， 重 新 启动 系统 ， 使 用 命令 
modprobe 安 闭 ahci 模 块 ， 并 使 用 命令 lsmod 查 看 内 核 安装 的 模块 ， 如 图 4-18 
所 示 。 
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bash-4.2# modprobe ahci 
ahci;: SS3 flag set, parallel bus scan disabled 
hci QQ000:00:0d.0: AHCI 0Q001.0100 32 slots 1 ports 3 Gbps Qx1 impl SATA mode 
.0: flags: b4bit mcd stag only cece 
: ahci 
: SATA max UDMA/133 abar m8192@0xfo806600 port QOQxf QB8BO6100 irg 1 
: SATA link up 3.0 Gbps (SStatus i123 SControl 300) 
: ATA-6: VBOX HARDDISK, 1.0, max UDMhA“133 
167?7?7?216 sectors, multi 128: LBA48 NCQ (depth 31/32) 
| 
:0:0; Direct-fccess a | UBOX HARDDISK 1.0 PQ: 0 ANSI: 5 
[sda]l] 16777216 512-bute logical blocks: (8.58 GB/8.00 GiB) 
[sda] Write Protect is off 
[sda] Write cache: enabled, read cache: enabled, doesn’t support DPO 


sdaz 
[sda] httached SC3I disk 
i 1smod 
3ize Used bu 
17351 
17049 


OP 四 自 W @ 固 右 ct | 


图 4-18 使 用 modprobe 加 载 ahci 模 块 


根据 lsmod 的 输出 可 见 ， 虽然 我 们 并 没有 明确 的 指示 modprobe 加 载 模 块 
libahci， 但 是 modprobe 根 据 modules.dep.bin 中 记录 的 依赖 关系， 目 动 加 载 了 
ahci 依 赖 的 模块 libahci 。 


4.6 自动 加 载 硬 盘 控 制 器 驱动 


在 前 面 ， 我 们 以 Intel 的 工作 在 AHCI 模 式 下 的 SATA 硬 盘 探 制 器 为 例 ， 展 
示 了 如 何 加 载 硬盘 控制 器 的 驱动 。 但 是 ， 除 非 是 为 一 球 特 定 的 租 入 式 设备 
定制 的 系统 ， 否 则 ， 对 于 一 个 通用 设备 来 说 ， 比 如 PC， 我 们 是 不 能 假定 硬 
件 使 用 的 硬盘 控制 器 的 。 因 此 ， 合 理 的 方法 应 该 是 根据 具体 的 硬盘 控制 器 
加 载 对 应 的 驱动 模块 。 但 是 依靠 用 户 自己 手动 来 完成 吗 ? 姑且 不 提 是 否 方 
便 易 用 ， 除 非 专业 用 户 ， 否 则 普通 用 户 如 何 知道 应 该 加 载 哪 些 驱 动 模块 


呢 ? 


从 2.6 版 内 核 开始 ，Linux 采 用 udev 管 理 驱 动 模块 的 加 载 以 及 设备 节点 的 
管理 。 每 当 内 核发 现 新 的 设备 ， 便 通过 NETLINK 向 用 户 空间 发 送 新 设备 事 
件 ， 该 事件 中 记录 了 设备 的 相关 信息 。 用 户 空间 的 udev 服 务 进程 收 到 内 核 
事件 后 ， 根 据 事件 中 携带 的 信息 ， 首 先 判断 该 设备 的 驱动 是 否 已 经 加 载 ， 
如 果 没 有 ， 则 加 载 驱 动 。 驱 动 加 载 后 ， 内 核 会 再 次 向 用 户 空间 报告 发 现 新 
设备 事件 ， 这 时 设备 已 经 成 功 驱动 了 ， 并 且 主 次 设备 号 等 信息 也 已 经 准备 
好 了 ，udev 收 到 事件 后 ， 或 者 为 设备 建立 节点 ， 或 者 执行 某 些 特定 的 操 
作 。 整 个 过 程 如 图 4-19 所 示 。 


Kernel Driver Core 
(The kernel driver cores (pci,usb...) read the device/vendor id and other device attributes) 


“add@/devices/pci0000:00/0000:00:1f.2\0|ACTION=add\0MODALIAS=pci:v00008086...” 


Udevd 
(Create a process for each uevent) 


Udev Event Process 


Match event to rules 
Load Modules Create/remove device nodes ee en 
(modprobe $env{ MODALIAS)) (mknod) Rog i 


modules.alias.bin， 
modules.dep.bin, ... 


图 4-19 目 动 加 载 设备 驱动 过 程 


读者 可 能 会 有 一 点 疑问 : 既然 有 了 devtmpfs， 为 什么 还 需要 udev? 


首先 ， 也 是 最 重要 的 一 点 ，devtmpfs 仅 是 记录 了 设备 驱动 注册 的 节点 。 
udev 除 了 创建 设备 下 点 外 ， 还 要 负责 加 载 设 备 张 动 。 后 者 是 devtmpfs 所 不 能 
实现 的 ，devtmpfs 仅 是 一 个 被 动 的 记录 数据 的 文件 系统 而 已 。 


其 次 ， 使 用 udev， 在 发 现 新 设备 或 者 设备 发 生 了 更 新 时 ， 可 以 有 机 会 
执行 某 些 特定 的 动作 。 比 如 在 建立 新 设备 时 ， 为 设备 市 点 建立 额 外 的 符号 


下 面 我 们 惑 分 别 讨论 一 下 上 面 描述 的 各 个 过 程 。 


4.6.1 内核 同 用 户 空 间 发 送 事件 


PC 机 上 的 硬盘 控制 器 ， 无 论 是 IDE 接 口 的 ， 还 是 SATA 接 口 的 ， 一 般 都 
是 通过 PCI 总 线 连接 到 计算 机 上 的 。 内 核 在 引导 时 ，PCI 子 系统 将 进行 初始 
化 ， 枚 举 总 线 上 的 设备 ， 并 和 演 试 为 设备 匹配 驱动 ， 然 后 将 收集 到 的 设备 相 
关 信 息 组 织 为 uevent 事 件 ， 接 着 调用 kobject_uevent， 通 过 NETLINK 将 组 织 
好 的 uevent 发 送 到 用 户 空间 ， 通 知 udev 有 新 设备 了 。 简 单 地 讲 ， 内 核 的 工作 
束 是 探测 并 收集 设备 信息 ， 将 其 包装 到 uevent 事 件 中 ， 然 后 发 送 到 用 户 空 
间 。 


事实 上 ， 无 论 是 发 现 新 的 设备 ， 还 是 有 新 的 驱动 载 入 ， 换 或 是 用 户 疝 
sysfs 中 的 uevent 写 入 字符 串 ， 内 核 都 将 调用 函数 kobject_uevent 回 用 户 空 间 发 
送 事件 ， 其 代码 如 下 所 示 : 


linux-3.7.4/1lib/kobject uevent.c 
int kobject uevent (struct kobject *kobj, ...) 


return kobject uevent env (kobj, action, 


int kobject uevent envl(struct kobject *kobj, 


struct kobj uevent env *env; 
const struct kset. uevent ops *uevent ops; 


/* search the kset we belong to */ 

top kob]j] = kobj; 

while 
top kobj = top kobj->parent; 

kset = top kobj->kset; 

uevent ops = kset->uevent ops; 


env = kzalloc (sizeof (struct kobj uevent env), 


retval = 
和 省 


add uevent varlenyv, 
(retval) 
goto exit; 
retval = add uevent varl(lenyv, 
1 (rxetval) 

goto exit; 
retval = add uevent varl(enyv, 


"ACTION=%s", 


"DEVPATH=%s", 


if (uevent ops && uevent ops->uevent) { 


retval = uevent ops->uevent (kset, 


(!top kobj->kset && top kobj->parent) 


"SUBSYSTEM=%s", 


kobj, 


NULL); 


so 


GFP KERNEL) ; 


action string); 


devpath)，; 


subsystem); 


env); 


结构 体 kobj_uevent_env 用 来 保存 收集 到 的 设备 相关 信息 ， 所 以 在 函数 


kobject_uevent_env 中 ， 首 先 为 kobj_uevent_env 申 请 了 


一 块 内 存 ， 


即 变量 env 


指 同 的 内 存 ， 用 来 临时 存放 准备 发 送 到 用 户 罕 


然后 问 该 内 存 中 添加 了 三 个 


SUBSYSTEM。 其 中 ACTION 指 的 是 热 播 拔 的 动作 ， 


zs 间 的 设备 相关 信息 。 


默认 的 变量 ， 包 括 ACTION、DEVPATH 和 


如 "add"，"remove"，"change" 等 。DEVPATH 指 的 是 设备 在 sysfs 文 件 系统 中 
注册 的 设备 路 径 ， 比 如 笔者 的 硬盘 sda 的 DEVPATH 

是 "/devices/pci0000:00/0000:00:1f.2/atal/hostO/target0:0:0/0:0:0:0/block/sda" 。 
SUBSYSTEM 一 般 是 指 设备 所 在 的 总 线 ， 比 如 笔者 的 硬盘 是 挂 在 PCI 总 线 上 
的 ， 因 此 该 变量 的 值 是 "pci"。 


在 Linux 的 设备 模型 中 ， 除 了 总 线 、 设 备 以 及 驱动 这 些 对 象 外 ， 还 定义 
了 集合 ， 有 某 些 相似 特性 的 kobject 将 被 组 织 到 一 个 集合 中 。 所 以 我 们 看 
到 ， 在 函数 kobject_uevent_env 的 开头 ， 寻 找 硬盘 控制 器 所 属 的 集合 ， 并 在 
问 uevent 中 添加 了 三 个 默认 的 变量 后 ， 调 用 硬盘 控制 器 所 属 的 集合 的 
uevent_ops 中 的 范 数 uevent 继 续 向 uevent 中 追加 变量 。 对 于 硬盘 控制 器 来 说 ， 
其 所 属 的 集合 是 devices_kset， 这 是 PCI 总 线 在 初始 化 设备 时 设 定 的 ， 相 关 定 
> 


linux-3.7.4/drivers/base/core.c 


static const struct kset uevent ops device uevent ops = { 
:Lter = dev uevent. filter; 
.name = dev_ uevent name, 
.Uevent = dev_ uevent, 


}; 


static int dev uevent (struct kset *kset, struct kobject *kobj, 
struct kobj uevent env *env) 


struct device *dev = kob]j to dev (kobj); 
int retval = 0; 


/* add device node properties if present */ 
if (MAJOR(dev->devt)) { 

const char *tmp; 

const char *name; 

umode t mode = 0; 


add uevent varlenv, "MAJOR=%$u", MAJOR (dev->devt)); 
add uevent varlenv, "MINOR=%$u", MINOR(dev->devt)); 
name = device get devnode(dev, &mode, &tmp); 
if (name) { 

add uevent varlenv, "DEVNAME=%s", name); 

kfree (tmp); 

if (mode) 

add uevent varlenv, "DEVMODE=%#0o", mode & 0777); 


if (dev->type && dev->type->name) 
add uevent varlenv, "DEVTYPE=%s", dev->type->name); 


if (dev->driver) 
add uevent varlenv, '"DRIVER=%s'", dev->driver->name); 


/* have the bus specific function add its stuff */ 
if (dev->bus && dev->bus->uevent) { 
retval = dev->bus->uevent (dev, env); 


dev_uevent 回 uevent 中 继续 增加 一 些 设备 相关 的 变量 ， 包 括 设备 世上 点 的 
主 次 设备 号 、 名 称 、 设 备 节点 的 读 、 写 和 执行 权限 、 设 备 的 类 型 以 及 驱动 
模块 的 名 称 等 准备 发 送 到 用 户 空 间 的 变量 。 在 设备 枚 举 阶段 ， 因 为 设备 还 


没有 被 豫 动 ， 所 以 这 些 信息 是 没有 的 。 只 有 当 设 备 被 正确 地 张 动 后 ， 内 核 
向 用 户 空间 发 送 的 uevent 中 才 包 含 这 些 信息 。 


除了 设备 信息 外 ， 设 备 所 属 的 总 线 也 可 能 需要 向 用 户 空间 报告 一 些 设 


备 所 在 的 总 线 的 相关 人 信息。 因此， 如 宋 设 备 属于 某 个 总 线 ， 


函数 dev_uevent 


则 还 要 调用 设备 所 属 总 线 的 event 函 数 。PCI 的 设备 总 线 类 型 pci_ bus_type 及 


其 中 的 uevent 男 


函数 代码 如 下 : 


linux-3.7.4/drivers/pci/pci-driver.c 


struct bus type pci bus type = { 


.name = Mo 
.match = pci bus match, 
.uevent = pci uevent, 


]y 


linux-3.7.4/drivers/pci/hotplug.c 


int pci uevent (struct device *dev, struct kobj uevent env *env) 


{ 


struct pci dev *pdev; 


pdev = to pci dev(dev); 


4f 


二 王 


2 


让 


(add uevent varlenv, "PCI CLASS=%04X", pdev->class)) 
return -ENOMEM; 


(add uevent varl(lenv, "PCI ID=%04X:%04X", pdev->vendor, 
pdev->device)) 
return -ENOMEM ; 


(add uevent varl(lenv, "PCI_ SUBSYS ID=%04X:%04X", 
pdev->subsystem vendor, pdev->subsystem device)) 


return -ENOMEM; 


(add uevent varlenv, "PCI SLOT NAME=%s", pci name (pdev))) 
return -ENOMEM; 


(add uevent var (enV， 


"MODALIAS=pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x", 


pdev->vendor, pdev->device, 
pdev->subsystem vendor, pdev->subsystem device, 
(u8) (pdev->class >> 16), (u8) (pdev->class >> 8)， 
(u8) (pdev->class))) 

return -ENOMEM ; 


return 0; 


pci_uevent 又 向 uevent 中 追加 了 pci class、vendor id 、device id 以 及 
MODALIAS 等 变量 ， 其 中 MODALIAS 需 要 重点 关注 ， 其 是 由 设备 所 在 总 
线 、vendor ID、device ID 等 相关 参数 连接 而 成 的 一 个 字符 串 。 在 接 下 来 的 
章节 中 ， 读 者 将 看 到 ， 用 户 空间 的 udev 恰 恰 就 是 根据 这 个 变量 为 设备 匹配 
驱动 模块 的 。 


除了 总 线 外 ， 如 果 硬 盘 控 制 器 所 属 的 class 或 者 type 也 需要 继续 向 uevent 
中 追加 变量 ， 则 继续 调用 硬盘 控制 器 所 属 的 class 或 者 type 中 的 相应 的 函数 ， 
这 里 不 再 继续 分 析 了 。 最 终 ， 内 核 向 用 户 空间 发 送 的 uevent 事 件 包含 的 大 致 
的 内 容 如 下 ， 其 中 不 同 变量 之 间 使 用 ^\0” 进 行 分 隔 。 


"add@/devices/pci0000:00/0000:00:1f.2\0 

ACTION=add\0 

DEVPATH=/devices/pci0000:00/0000:00:1f.2\0 

SUBSYSTEM=pci\0 

PCI CLASS=10601\0 

PCI ID=8086:1C03\0 

PCI_ SUBSYS ID=17AA:21CE\0 

PCI SLOT NAME=0000:00:1f.2\0 
MODALIAS=pci:v00008086d00001C03sv000017AAsd000021CEbc01lsc06i01 \0 
SEQNUM=1206\0" 


当 伴 随 着 热 插 拔 事件 一 同 发 往 用 户 空 间 的 变量 准备 完毕 后 
kobject_uevent_env 使 用 内 核 和 用 户 空 间 的 通信 协议 NETLINK 癌 用 户 空间 报 
告 事件 ， 代 码 如 下 : 


1Linux-3.7.4/1Lib/kobject_uevent .c 


int kobject uevent env(struct kobject *kobj, ...) 


{ 
struct sk buff *skb; 


skb = alloc skbl(len + env->buflen, GFP KERNEL); 
if (skb) { 
char *scratch; 


/* add header */ 
scratch = skb put (skb, len); 
sprintf (scratch, "%s@%s", action string, devpath); 


/* copy keys to our continuous event payload buffer */ 
for (i = 0; i < env->envp idx; i++) { 

len = strlen(env->envp[i]) + 1; 

scratch = skb put (skb, len); 

strcpy (scratch, env->envp[i]); 


} 


NETLINK CB(skb) .dst group = 1; 

retval = netlink broadcast filtered(uevent sock, skb, 
0, 1, GFP KERNEL, 
kobj_ bcast filter, 
kobj); 


kobject_uevent_env 申 请 了 一 个 结构 体 sk_buff 类 型 的 变量 skb， 这 个 skb 束 
是 用 来 封装 报 文 的 。 报 文 以 形 
如 "ACTION@DEVPATH"” (如 "add@/devices/pci0000:00/0000:00:1f.2") 的 格 
式 开头 ， 紧 接着 的 消息 体 中 封装 的 就 是 前 面 收集 到 的 存储 在 变量 env 中 的 变 


量 。 


至 此 ， 对 于 加 载 硬盘 控制 器 驱动 这 个 任务 ， 内 核 已 经 完成 了 它 的 使 
命 ，PCI 子 系统 获取 硬 副 控制 器 的 信息 ， 并 将 其 通过 NETLINK 抛 到 了 用 户 
空间 。 接 下 来 ， 该 用 户 空 间 的 udev 出 场 了 。 


4.6.2 _ udev 加载 豫 动 和 建立 设备 刷 点 


前 面 我 们 探讨 了 内 核 同 用 户 空 间 报告 uevent 事 件 的 过 程 。 这 一 六， 我 们 
来 讨论 udev 是 如 何 根据 内 核 报 告 的 uevent 事 件 加 载 硬 盘 控 制 器 驱动 以 及 建立 


设备 斑点 的 。 


udev 是 用 户 空间 动态 管理 设备 的 机 制 ， 包 括 加 载 驱动 、 管 理 设备 节点 
。 udev 机 制 的 核心 是 其 服务 进程 udevd。 当 启动 过 程 进入 用 户 空间 阶段 

百 ，udevd 将 被 局 动 。udevd 局 动 后 ， 首 移 读 取 并 分 析 所 有 的 规则 文件 ， 并 
将 其 缓存 在 内 存 中 。 一 般 情 况 下 ， 系 统 默认 的 规则 文件 存放 

在 /lib/udev/rules.d 目 孙 下 ， 用 户 目 定义 的 规则 存放 在 /etcudevrules.d 上 目录 

下 。 每 当 动态 地 增加 、 删 除 或 者 改变 某 个 规则 文件 时 ，udevd 将 更 新 其 缓存 
在 内 存 中 的 规则 。 然 后 ，udevd 通 过 NETLINK 协 议 ， 监 听 并 处 理 来 自 内 核 的 
uevent 事 件 。 每 当 udevd 收 到 一 个 内 核 的 uevent，udevd 均 创建 一 个 单独 的 子 
进程 处 理 uevent 。 


类 


对 于 每 个 内 核 报告 的 uevent，udevd 根 据 uevent 中 的 变量 逐个 匹配 规则 。 
规则 文件 通 音 以 数字 开头 ， 数 字 小 的 移 进 行 匹 配 。 大 每 个 规则 文件 中 包含 
知 干 个 规则 ， 同 一 规则 不 允许 断 行 ， 每 个 规则 人 至 少 包含 一 个 key-value 对 ， 
每 个 key-value 对 之 间 使 用 逗号 分 隔 。 可 以 将 规则 理解 为 由 匹配 条 件 和 赋值 
动作 组 成 ， 当 所 有 的 匹配 条 件 都 满足 后 ， 赋 值 动作 束 会 发 生 。 规 则 中 可 以 
加 载 驱 动 模 块 ; 规定 如 何 给 设备 接点 命名 、 建 立 符号 连接 ; 设备 连接 和 断 
开 时 分 别 执行 指定 的 程序 等 。 


前 面 我 们 看 到 内 核 在 发 现 新 设备 时 会 将 设备 的 一 些 信息 通过 NETLINK 
发 送 到 用 户 空间 ，udev 接 收 到 事件 后 ， 如 果 发 现 设备 尚未 被 驱动 ， 将 尝试 
加 载 驱 动 模块 。 那 么 udev 如 何 确 定 设备 对 应 的 驱动 模块 呢 ? 一 般 而 言 ， 根 
据 设 备 的 vender ID 和 device ID 就 可 以 标识 一 类 设备 ， 当 然 有 的 也 需要 根据 
subvendor ID 和 subdevice ID 进一步 细 分 。 而 在 驱动 代码 中 ， 人 恰恰 使 用 这 些 设 
备 信 息 明 确 声明 了 其 可 以 文 持 的 设备 。 以 驱动 AHCI 模 式 的 SATA 硬 盘 控制 器 
驱动 为 例 : 


linux-3.7.4/vi drivers/ata/ahci.c 
static const struct pci device id ahci pci tbl[] = { 
/* Intel */ 
{ PCI VDEVICE(INTEL, 0x2652), board ahci }, /* ICH6 */ 
{ PCI VDEVICE (INTEL, 0x2653), board ahci }, /* ICH6M */ 
{ PCI_ VDEVICE (INTEL, Ox1c03), board ahci 让 /* CPT AHCI */ 


/* AMD */ 
{ PCI VDEVICE(AMD, 0x7800), board ahci }, /* AMD Hudson-2 */ 


/* NVIDIA */ 
{ PCI_ VDEVICE (NVIDIA, 0x044c), board ahci mcp65 }, /* MCP65 */ 


ID table 中 的 每 一 项 表示 该 驱动 支持 的 一 类 设备 ， 根 据 PCI_VDEVICE 的 
定义 : 
#define PCI VDEVICE (vendor, device) 


PCI VENDOR ID ##vendor, (device), 二 
PCI ANY ID, PCI ANY ID, 0, 0 


以 ahci_pci_tbl 中 的 第 一 项 为 例 ， 该 项 声明 了 该 驱动 支持 vender ID 为 
PCI_VENDOR ID INTEL (0x8086) ，device ID 为 0x2652，subvendor ID 、 


subdevice ID 为 任意 的 Intel SATA 控 制 器 。 


内 核 将 ID table 中 的 每 一 项 中 的 信息 按照 一 定 的 格式 组 合 起 来 ， 作 为 驱 
动 的 一 个 别名 。 这 些 别名 存储 在 编译 好 的 驱动 模块 中 ， 模 块 安装 后 ， 需 要 
使 用 工具 depmod 将 其 提取 出 来 并 存储 在 /lib/modules/'uname-r' 目 录 下 的 
modules.alias.bin/modules.aliass 中 ， 如 同 前 面 讨论 的 modules.dep 和 


modules.dep.bin 的 关系 一 样 ，modules.alias.bin 与 modules.alias 完 全 相同 ， 只 
不 过 modules.alias.bin 是 为 了 加 快 搜索 速度 采用 Trie 树 存储 的 。 很 多 读者 可 能 
会 说 ， 编 译 安 装 模 块 时 从 来 没有 显示 执行 depmod 啊 ， 那 是 因为 make 等 安装 
脚本 已 经 蔡 我 们 调用 了 这 个 命令 。 


我 们 可 以 使 用 工具 modinfo 来 查看 驱动 模块 的 相关 信息 ， 下 面 是 查看 驱 
动 模块 ahci 的 别名 信息 。 
vita@baisheng:/vitas$ modinfo -F alias \ 
sysroot/lib/modules/3.7.4/kernel/drivers/ata/ahci .ko 
pci:v*d*sv*sd*bc0lsc06i01* 
pci:v00001B21d0000061l2sv*sd*bCc*sc*i* 


pci:v00001B21d000006llsv*sd*bc*sc*i* 


pci:v00008086d00002653sv*sd*bCc*scC*1i* 
pci:v00008086d00002652sv*sd*bCc*sc*i* 


上 述 答 出 表示 张 动 模块 ahci 可 以 驱动 别名 
为 "pci:v*d*sv*sd*bc01sc06i01*"、"pci:v00001 
B21d00000612sv*sd*bc*sc*i*" 等 的 设备 ， 其 中 “*” 表 示 可 以 匹配 任意 ID 。 


通过 depmod 生 成 的 典型 的 modules.alias 文 件 如 下 所 示 : 


alias pci:v00008086d00001C03sv*sd*bc*sc*i* ahci 
alias pci:v00008086d00001C02sv*sd*bc*sc*i* ahci 


alias pci:v00001101d00001622sv*sd*bc*sc*i* sata inicl62x 
alias pci:v00001095d0000353lsv*sd*bc*sc*i* sata si]24 


显然 ， 这 个 文件 束 是 简单 地 将 别名 和 驱动 名 称 对 应 起 来 。 


前 面 讨 论 内 核 向 用 户 空间 发 送 uevent 时 ， 我 们 看 到 ， 内 核 将 在 uevent 的 
消息 体 中 封装 一 个 变量 MODALIAS， 其 值 形 
如 "pci:v00008086d00001C03sv000017AAsd000021CEbc01s c06i01"。 看 上 去 
是 不 是 与 驱动 的 别名 一 致 ? 没 错 ， 内 核 的 设计 者 们 设计 了 这 个 机 制 ， 内 核 
创建 变量 MODALIAS 和 模块 创建 别名 采用 相同 的 算法 。 当 udevd 收 到 内 核 
uevent 后 ， 从 uevent 中 提取 这 个 字符 串 ， 然 后 将 这 个 字符 串 作 为 modprobe 的 
参数 。modprobe 首 先 查 找 文件 modules.alias.bin， 将 该 别名 对 应 的 模块 找 
到 。 以 该 别名 为 例 ， 显 然 其 会 与 上 面 modules.alias 文 件 片 断 中 的 第 一 行 匹 配 
成 功 ， 而 该 行 明 确 表明 该 别名 对 应 的 驱动 模块 是 ahci， 因 此 ，modprobe 将 加 
载 模块 ahci 。 


udev 设 计 了 规则 文件 80-drivers.rules 用 来 摘 述 如 何 加 载 驱动 模块 ， 以 
Vv173 版 本 的 udev 的 80-drivers.rules 为 例 : 


udev-173/rules/rules.d/80-drivers.rules 
ACTION=="remove", GOTO="drivers _ end" 


DRIVER!="?*", ENV{MODALIAS}=="?*", RUN+='"/sbin/modprobe -bv 
$env {MODALIAS}" 


LABEL="drivers end" 


我 们 先 来 看 第 一 个 规则 ， 该 规则 表示 如 果 uevent 的 动作 是 删除 设备 
(remove) ， 则 忽略 下 面 所 有 规则 ， 什 么 也 不 用 做 。 


第 二 个 规则 包含 两 个 匹配 条 件 ， 一 个 赋值 动作 。 其 中 “?* 匹 配 一 个 字 
符 ,“*” 匹 配 0 或 多 个 字符 。 这 个 规则 表达 的 含义 是 : 当 设 备 还 没有 加 载 驱 
动 ， 即 环境 变量 DRIVER 的 值 为 空 ， 并 且 环 境 变量 MODALIAS 的 值 非 空 ， 
那么 调用 modprobe 加 载 驱动 。 我 们 看 到 这 里 加 载 模块 的 方式 就 是 采用 我 们 
前 面 讨论 的 别名 的 方式 。 这 里 追加 到 环境 变量 RUN 中 的 程序 ， 如 果 不 给 出 
绝对 路 径 ， 将 在 /lib/mdev 目 录 下 和 寻找， 如 果 这 个 程序 不 在 /lib/udev 目 录 下 ， 
必须 给 出 绝对 路 径 。 


80-drivers.rules 也 会 包含 对 个 别 特殊 subsystem 类 型 的 设备 的 特殊 处 理 ， 
我 们 这 里 不 作 过 多 讨论 。 


一 旦 碟 动 被 正确 加 载 ， 并 且 设 备 需 要 在 用 户 空 间 建立 设备 节点 ， 那 么 
内 核 向 用 户 空 间 再 次 报告 的 uevent 中 会 包含 创建 设备 节点 需要 的 主 次 设备 号 
以 及 市 后 的 名 称 等 环境 变量 ， 类 似 于 下 面 的 这 个 示例 uevent 事 件 。 事 实 上 ， 
在 发 现 设备 、 加 载 驱 动 过 程 中 ， 内 核 一 般 会 多 次 癌 用 户 空 间 报告 uevent 事 
件 ， 只 有 设备 和 驱动 匹配 成 功 后 发 送 的 事件 中 才 会 包含 主 次 设备 号 等 变 


=} 


里 “” 


"add@/devices/pci0000:00/0000:00:1f.2/atal/host0/target0:0:0/0:0:0:0/block/sda/ 
sdal\0 


ACTION=add\0 

DEVPATH=/devices/pci0000:00/0000:00:1f.2/atal/host0/target0:0:0/0:0:0:0/block/ 
sda/sdal\0 

SUBSYSTEM=block\0 

DEVNAME=sdal\0 


DEVTYPE=partition\0 
MAJOR=8\0 

MINOR=1\0 
SEQNUM=1204\0" 


该 消息 中 ， 内 核 为 udev 创 建设 备 节点 提供 了 必要 的 变量 ， 包 括 主 设备 
号 为 8， 次 设备 号 为 1， 内 核 提供 的 该 设备 节点 的 名 字 为 sdal。 当 udevd 收 到 
的 uevent 消 息 中 ， 如 果 uevent 的 变量 中 包含 设备 号 ， 则 使 用 系统 调用 mknod 
创建 设备 万 点 。 


4.6.3 “处理 冷 搬 拔 设备 


前 面 我 们 讨论 了 动态 加 载 驱动 的 整个 过 程 。 但 是 不 知道 读者 想 过 没 
有 ， 对 于 人 磁盘 这 种 非 热 插 拔 设备 ， 如 果 驱 动 没有 编译 进 内 核 ， 那 么 当 内 核 
引导 枚 举 设 备 时 ， 系 统 运行 在 内 核 空间 ， 尚 未 进入 用 户 空间 ， 更 谈 不 上 启 
动用 户 空间 的 udev 服 务 了 ， 因 此 内 核发 送 到 用 户 空间 的 uevent 目 然 会 被 丢 
掉 ， 更 别提 加 载 硬 盘 驱 动 模块 和 建立 设备 节 感 了 。 


为 了 解决 这 个 问题 ， 开 发 人 员 基 于 sys 文 件 系统 设计 了 一 种 巧妙 的 机 
制 。 在 Linux 操 作 系 统 进 入 用 户 空 间 ，udevd 启 动 后 ， 通 过 sys 文 件 系统 请 求 
内 核 重 新 发 出 uevent。 此 时 udevd 已 经 局 动 了 ， 就 会 收 到 uevent， 然 后 结合 这 
些 事件 和 规则 ， 完 成 驱动 的 加 载 、 设 备 广 点 的 建立 等。 我 们 可 以 将 这 个 过 
程 看 作 是 内 核 和 udev 导 演 的 一 出 戏 ， 对 于 冷 播 拔 的 设备 ， 模 拟 了 一 遍 热 插 
拔 的 过 程 。 


下 面 我 们 人 窒 单 探讨 一 下 这 个 机 制 的 原理 。 


当 新 设备 注册 时 ， 内 核 将 调用 device_create_file 在 sys 文 件 系 统 中 为 设备 
注册 一 个 名 字 为 uevent 的 文件 ， 当 用 户 空间 的 程序 读 取 该 文件 时 ， 内 核 将 调 
用 函数 show_uevent 处 理 用 户 的 读 操作 ， 而 当 用 户 空 间 的 程序 向 该 文件 写 入 
时 ， 内 核 将 调用 函数 store_uevent 处 理 用 户 的 写 操作 。 我 们 以 函数 
store_uevent 为 例 ， 看 看 内 核 是 如 何 处 理 用 户 的 写 操作 的 。 画 数 store_uevent 
代码 如 下 : 


linux-3.7.4/drivers/base/core.c 


static: ssize t store uevent (struct device *dev; struct 


{ 


device attribute *attr, const char *buf, size t count) 
enum kobject action action; 


if (kobject action type(buf, count, &action) == 0) 
kobject uevent (&dev->kobj, action); 
else 
dev errl(dev, "uevent: unknown action-string\n'"); 
return count; 


store_uevent 的 参数 buf 指 癌 复制 目 用 户 空间 的 用 户 写 入 的 字符 串 。 为 数 
kobject_action_type 根 据 buf 中 的 字符 串 ， 来 决定 发 送 给 用 户 空间 的 event 的 
类 型 。 写 入 的 字符 串 和 发 送 的 事件 类 型 间 的 对 应 天 系 的 代码 如 下 所 示 。 


linux-3.7.4/include/linux/kobject.h 


enum kobject action { 
KOBJ_ADD, 
KOBJ REMOVE, 
KOBJ CHANGE., 
KOBJ MOVE, 
KOBJ ONLINE, 
KOBJ OFFLINE, 
KOBJ MAX 


}; 


linux-3.7.4/1ib/kobject uevent.c 


static const char *kobject actions[] = { 
[KOBJ ADD] = "add", 
[KOBJ REMOVE] = "remove'", 
[KOBJ CHANGE] = "change", 
[KOBJ MOVE] = "move", 
[KOBJ ONLINE] = "nonline", 
[KOBJ OFFLINE] = "offlliner. 


}; 


也 就 是 说 ， 当 用 户 空 间 的 程序 向 该 属性 文件 写 入 字符 串 "add" 时 ， 画 数 
kobject_action_type 认 为 用 户 空 间 的 程序 要 求 KOBJ_ADD 类 型 的 事件 ， 于 是 


调用 kobject_uevent 回 用 户 空 间 发 送 KOBJ_ADD 类 型 的 uevent。 


利用 这 种 机 制 ， 我 们 可 以 在 用 户 空间 的 udev 服 务 程序 启动 后 ， 向 所 有 
设备 的 属性 文件 uevent 写 入 "add" 字 符 串 ， 请 求 内 核 重 新 发 送 一 电 
KOBJ_ADD 事 件 ， 模 拟 一 过热 插 拔 动作 。 如 此 ，udevd 束 可 以 收 到 这 些 事 
件 ， 完 成 驱动 加 载 、 设 备 节 点 创 建 等 工作 。 


为 此 ，udev 提 供 了 一 个 管理 工具 udevadm， 我 们 可 以 使 用 这 个 工具 请 求 
内 核 重 新 发 送 设备 相关 事件 。 假 设 请 求 内 核对 全 部 设备 模拟 一 遍 热 插 拔 ， 
即 重新 发 送 事件 KOBJ_ADD， 则 使 用 如 下 命令 : 


udevadm trigger --action=add 


我 们 来 简单 地 看 一 下 这 个 命令 至 后 的 代码 : 


udev-173/udev/udevadm-trigger.c 


const struct udevadm cmd udevadm trigger = { 
.name = "trigger", 
.cmd = adm trigger, 
.help = "request events from 七 he kernel", 


后 


static int adm trigger(struct udev *udev, int argc, char *argv[]) 


{ 


switch (device type) { 


case TYPE DEVICES: 
udev enumerate scan devices (udev enumerate); 
exec list (udev enumerate, action); 


} 


static void exec list(struct udev enumerate *udev enumerate, 
const char *action) 


{ 


struct udev *udev = udev enumerate get udev(udev enumerate); 
struct udev list entry *entry; 


udev list entry foreach (entry, 


udev_ enumerate get list entry(udev enumerate)) { 
char filename [UTIL PATH SIZE]; 
int fd; 


util strscpyl (filename, sizeof (filename), 
udev list entry get name (entry), "/uevent", NULL); 
fd = openlfilename, O WRONLY); 


if (writel(fd, action, strlen(action)) < 0) 


info(udev;: "error writing "%sa' to '%e's 和 NO action; 
filjename); 
close (fd); 


根据 上 面 代码 可 见 ，udevadm 的 trigger 命 令 对 应 的 函数 是 adm_trigger 。 
当 用 户 请 求 内 核 重 新 发 送 设备 相关 的 事件 时 ，adm_trigger 首 先 调 用 
udev_enumerate_scan_devices 在 sys 文 件 系统 中 寻找 设备 ， 使 用 udevadm 的 
trigger 命 令 时 我 们 可 以 指定 一 些 属性 ， 匹 配 特定 的 设备 。 但 是 无 论 如 何 ， 会 
有 多 个 设备 满足 匹配 条 件 的 情况 ， 比 如 我 们 上 面 的 命令 ， 没 有 任何 限制 条 
件 ， 那 么 内 核 将 匹配 所 有 设备 。 于 是 udev 在 结构 体 udev_enumerate 中 设计 了 
一 个 链表 ，udev_enumerate_scan_devices 将 找到 的 所 有 设备 连接 到 结构 体 
udev_enumerate 中 的 设备 链表 中 。 


然后 ，adm_trigger 调 用 函数 exec_list 遍 历 这 个 链表 ， 癌 这 些 设备 在 sys 文 
件 系统 中 注册 的 属性 文件 uevent 写 入 用 户 请 求 内 核 重 新 发 送 的 事件 类 型 对 应 
的 字符 串 。 比 如 ， 如 果 请 求 内 核发 送 KOBJ_ADD 类 型 的 uevent， 则 写 入 字符 
串 "add";， 如 果 请 求 内 核发 送 KOBJ_CHANGE 类 型 的 uevent， 则 写 入 字符 


串 "change"， 等 等 。 


4.6.4 编译 安装 udev 


前 面 几 市 我 们 探讨 了 相关 的 工作 原理 ， 从 本 市 开始 ， 我 们 开始 动手 实 
践 红 动 模块 的 目 动 加 载 过程 。 


因为 系统 启动 程序 systemd 和 udev 之 间 的 依赖 关系 ， 为 了 方便 开发 编 
译 ， 所 以 社区 中 已 经 将 udev 和 systemd 合 并 了 “。 但 是 本 书 中 我 们 不 讨论 
systemd， 为 了 减少 干扰 ， 本 书 中 使 用 尚未 合并 前 的 udev。 合 并 前 后 ，udev 
本 质 上 并 没有 什么 差别 。 


使 用 如 下 命令 编译 安装 udev (我 们 采用 的 版 本 是 udev 173) : 


vita@baisheng:/vita/builds$ tar xvf ../source/udev-173.tar.xz 
vita@baisheng:/vita/build/udev-173$ ./configure --prefix=/usr \ 
--sysconfdir=/etc --sbindir=/sbin --libexecdir=/lib/udev \ 
--disable-hwdb --disable-introspection \ 
--disable-keymap --disable-gudev 
vita@baisheng:/vita/build/udev-173$ make 
vita@baisheng:/vita/build/udev-173$ make install 


指定 --libexecdir 的 目的 是 告诉 安装 脚本 将 udev 的 规则 文件 以 及 一 些 
helper 程 序 安装 在 /lib/udev 目 录 下 。 我 们 使 用 --disable 选 项 禁 掉 udev 不 必要 的 
一 些 特性 ， 也 减少 了 udev 对 其 他 库 的 依赖 和 系统 的 复杂 性 。 


接 下 来 将 udevd、udevadm 以 及 相关 的 规则 文件 安装 到 initramfs 中 


vita@baisheng:/vitas$ ldd sysroot/sbin/udevd 

11DEt = /Vita/ay eroot/ iD/LiDEGR61 
libgcc s.so.1 => 
/vita/cross-tool/i686-none-linux-gnu/lib/libgcc s.so.1 
libewaore 二 > /vita/eyeroot /lib/libecsaos 


vita@baisheng:/vitas ldd sysroot/sbin/udevadm 

11BEt SOL S53 /vita/sv root/ TiD /LibDEt. 30 

libgcc s.so.1 => 
/vita/cross-tool/i686-none-linux-gnu/lib/libgcc s.so.1 

libe Bo.6 ss /vita/sveBroot/Lib/1libeBos6 


vita@baisheng:/vitas$ cp sysroot/sbin/udevd initramfs/bin/ 

vita@baisheng:/vitas$ cp sysroot/sbin/udevadm initramfs/bin/ 

vita@baisheng:/vitas$ mkdir -p initramfs/lib/udev/rules.d 

vita@baisheng:/vitas cp \ 
sysroot/lib/udev/rules.d/80-drivers.rules \ 
initramfs/lib/udev/rules.d/ 


udevd 和 和 udevadm 依 赖 的 库 在 前 面 已 经 复制 到 initramfs 中 了 ， 所 以 只 需 将 
udevd、udevadm 和 和 加载 驱 动 的 规则 ， 即 80-drivers.rules， 复 制 到 initramfs 妇 ] 
可 。 


4.6.5 配置 内 核 文 择 NETLINK 


内 核 与 udevd 通 过 Unix Domain Sockets 使 用 NETLINK 协 议 进 行 通信 ， 
此 ， 我 们 需要 配置 内 核 支持 Unix Domain Sockets 与 NETLINK 协 议 。 配 置 步 
又 如 下 : 


1) 执行 make menuconfig， 出 现 如 图 4-20 所 示 的 界面 。 


BUS options (PCI etc.) ---> 
Executable file formats / Emulations ---> 


wi|] Networking support ---> 
Device Drivers ---> 


图 4-20 配置 内 核 支持 Unix domain sockets 和 NETLINK 协 议 (1) 


2) 在 图 4-20 中 ， 选 择 "Networking support"， 出 现 如 图 4-21 所 示 的 界 


--- Networkinc 
Networking optioms ---> 


Amateur Radio support (NEW) ---> 
CAN bus subsystem support (NEW) ---> 


图 4-21 配置 内 核 支持 Unix domain sockets 和 NETLINK 协 议 (2) 


3) 在 图 4-21 中 ， 选 择 "Networking options"， 出 现 如 图 4-22 所 示 的 界 
面 O 


< > Packet socket (NEW 
< 是 > Unix domain sockets 


< > UNIX: socket monitoring interface (NEW) 
< > PF KEY sockets (NEW) 


图 4-22 配置 内 核 支 持 Unix domain sockets 和 NETLINK 协 议 (3) 


4) 在 图 4-22 中 ， 选 中 "Unix domain sockets"。 


对 于 ，NETLINK 了 协议 ， 只 要 配置 内 核 文 持 网 络 ，NETLINK 协 议 默 认 吏 
被 支持 。 通 过 net 目 录 下 的 Makefile 可 以 清楚 地 看 到 这 一 点 : 


linux-3.7.4/net/Makefile 


obj-$ (CONFIG NET) += ethernet/ 802/ sched/ netlink/ 


4.6.6 配置 内 核 文 持 inotify 


为 udev 使 用 inotify 机 制 监 测 udev 的 规则 文件 是 否 发 生变 化 ， 所 
以 配置 内 核 使 其 文 持 inotify 机 制 ， 否 则 udevd 将 因为 初始 化 inotify 失 败 
而 退出 。 配 置 过 程 如 下 : 


1) 执行 make menuconfig， 出 现 如 图 4-23 所 示 的 界面 。 


[*] Networking support ---> 
Device Drivers ---> 


Firmware Drivers ---> 
日 File systems ---> 
Kernel hacking ---> 


4-23 配置 内 核 支持 inotify (1) 


2) 在 图 4-23 中 ， 选 择 "File systems"， 出 现 如 图 4-24 所 示 的 界面 。 


< > XFS filesystem syupport 
< > GFS2 file system support 


rR 


[ ] Filesystem wide access notification 


4-24 ”配置 内 核 支 持 inotify (2) 


3) 在 图 4-24 中 ， 选 中 "Inotify support for userspace"。 


4.6.7 “安装 modules.alias.bin 文 件 


在 安装 内 核 模 块 时 ， 安 装 脚本 最 后 会 自动 调用 depmod 创 建 
modules.alias.bin/modules.alias 文 件 。 我 们 直接 将 其 复制 到 initramfs 即 可 : 


vita@baisheng:/vitas$ cp \ 
sysroot/lib/modules/3.7.4/modules.alias.bin \ 
initramfs/lib/modules/3.7.4/ 


如 果 你 在 某 些 特殊 情况 下 ， 需 要 用 手动 执行 depmod 创 建 
modules.alias.bin、modules.dep.bin 等 文件 ， 相 应 命令 如 下 : 


vita@baisheng:/vitas depmod -b /vita/sysroot/ 3.7.4 


下 面 我 们 验证 一 下 modules.alias.bin 是 否 可 以 正确 工作 。 我 们 需要 安装 
两 个 工具 : 一 个 是 lspci， 这 个 工具 用 来 运行 在 目标 系统 上 ， 查 看 硬盘 设备 
在 PCI 总 线 上 的 位 置 ， 包 括 设备 所 在 的 总 线 、 设 备 号 等 ， 这 个 工具 在 软件 包 
pciutils 中 ; 男 外 一 个 是 coreutils 中 的 工具 cat， 其 已 经 编译 并 且 安 装 
在 /vita/sysroot 下 了 ， 我 们 将 其 直接 复制 到 initramfs 即 可 。 


我 们 首先 编译 安装]spci: 


vita@baisheng:/vita/builds tar \ 
XvE s/ource/peliutile=3,1al0 Gar 
vita@baisheng:/vita/build/pciutils-3.1.10$ make PREFIX=/usr \ 
ZLIB=nO SHARED=yes PCI COMPRESSED IDS=0 ol 
vita@baisheng:/vita/build/pciutils-3.1.10$ make PREFIX=/usr \ 
ZLIB=nO SHARED=yes PCI COMPRESSED IDS=0 1nstall 


将 lspci 及 其 依赖 的 库 安装 到 initramfs， 命 令 如 下 : 


vita@baisheng:/vitas ldd sysroot/usr/sbin/lspci 
LIiDBCi B63 = /vita/everoot/uar iD/1TibBBeli, S63 
LDO 3 /vita/eyeroot/liD/ALibe..86.6 


vita@baisheng:/vitas ldd sysroot/usr/lib/libpci.so.3 
libresolv.so.2 => /vita/sysroot/lib/libresolv.so.2 
libe so.6 Ey, /vitasyveroot/ lib/ltbe .S06 


vita@baisheng:/vitas ldd sysroot/lib/libresolv.so.2 
libe SO.6 SS /Vita/evVaroot/Lip/Dibe.s06 


vita@baisheng:/vitas$ cp sysroot/usr/sbin/lspci initramfs/bin/ 

vita@baisheng:/vitas$ cp -d sysroot/usr/lib/libpci.so.3* \ 
initramfs/l1ib/ 

vita@baisheng:/vitas$ cp -d sysroot/lib/libresolv* initramfs/lib/ 


lspci 将 依次 尝试 通过 sysfs 文 件 系 统 、proc 文 件 系统 以 及 直接 访问 并 口 的 
方式 列 出 PCI 总 线 上 的 设备 。 为 了 便于 人 们 理解 ， 社 区 中 维护 了 一 个 pci 数 据 
库 pci.ids， 该 数据 库 中 记录 了 ID 到 设备 信息 的 映射 。 当 lspci 碍 找到 设备 ID 
时 ， 其 使 用 设备 ID 到 pci.ids 中 去 匹配 设备 信息 。 因 此 除了 安装 lspci 及 依赖 的 
库 外 ， 我 们 还 需要 安装 pei 数据库 pci.ids，pci.ids 已 纪 ee 
中 ， 并 且 在 安装 ]spci 时 已 经 安装 到 目标 系统 的 根 文件 系统 下 ， 我 们 将 其 
制 到 initramfs 中 。 


vita@baisheng:/vitas$ mkdir -p initramfs/usr/share 
vita@baisheng:/vitas$ cp sysroot/usr/share/pci.ids \ 
initramfs/usr/share/ 


coreutils 中 的 cat 已 经 编译 并 且 安 装 在 /vita/sysroot 下 了 ， 我 们 直接 复制 到 
initramfs 即 可 。 


vita@baisheng:/vitas ldd sysroot/usr/bin/cat 
IIDG Son SS Yvita/svirooe/lb/ libeao6 
vita@baisheng:/vitas$ cp sysroot/usr/bin/cat initramfs/bin/ 


使 用 支持 NETLINK 和 inotity 的 内 核 以 及 新 的 initramfs 更 新 vita 系 统 ， 重 
启 后 运行 lspci， 运 行 结果 如 图 4-25 所 示 。 根 据 lspci 的 输出 可 见 ，SATA 控 制 
器 挂 在 总 线 号 为 0x00 的 PCI 总 线 上， 设备 号 为 0x0d 。 
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Switching to clocksource tsc 


bash-4.2# lspci 
:00.0 Host bridge: Intel Corporation 440FX - 82441FxX PNMC [Natoma] (rev QZ2) 
:O01.0 ISA bridge: Intel Corporation 823713B PIIx3 ISA [Natoma/Triton I1] 
:OQ1.1 IDE interface;: Intel Corporation 82371AB/EB/MB PIIx4 IDE (rev ©Q1) 
:02 .0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox Graphi 
Adapter 
:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controll 
(rev 02) 


:04.0 Syustem peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service 
:05.0 Multimedia audio controller: Intel Corporation 82801h66 hC 97 fAudio Contr 


(rev 01) 

.0 USB controller: fpple Inc. KeyLargo/Intrepid UsB 

.0 Bridge: Intel Corporation B2371AB/EB/MB PIIX4 ACPI (rev 08) 

:0 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) 3ATA Cont 
roller [AHCI mode] (rev 02) 


bash-4.2z# cat /sys/devices/pciQO000N\:00/0000\:O0\:0d .0/uevent 
PCI_CLASS=106O1 

PCI_ID=8086 :Zz829 

PCI_SUBSYS_ID=0000:0000 

PCI_SLOT_NAME=0000:00:0d .9 

0DALIAS=pci :v0000808640000282z93sv00000000sd400000000bcO1sc06 1i01 


bash-4.2z# _ 
装 昌 多 甲 自 人 多加 右 ctrl 


图 4-25 ”硬盘 控制 器 的 uevent 中 的 环境 变量 


根据 总 线 号 和 设备 号 就 可 以 确定 SATA 控 制 器 在 sysfs 文 件 系 统 中 的 路 
径 。 我 们 使 用 命令 cat 将 uevent 中 的 相关 变量 读 出 ， 根 据 输出 结果 可 见 ， 变 量 
MODALIAS 的 值 为 "pci:v000080 
86d00002829sv00000000sd00000000bc01sc06i01"。 我 们 使 用 这 个 
MODALIAS 的 值 加 载 模块 ， 如 图 4-26 所 示 。 
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bash-4.2# cat /sys/devices/pciOQ000\:00/0000、:00\:0d.0/uevent 
PCI_CLhSS=10601 
PCI_ID=8086:2829 
PCI_SUBSYS_ID=0000:0000 
PCI_SLOT NAME=0000:00:0d.0 
MODALIAS=pci :vOOQO08086d000028293sv00000000sd00000000bc01sc06 i01 
bash—4 ,zt 
bash—4.2# modprobe pci:vO00080386d400002829su00000000s 100000000bcO1lsc06i01 
mahci: S33 flag set, parallel bus Scan disabled 
ahci Q000:00:04.0: AHCI OQ01.0100 32 slots 1 ports 3 Gbps 0Oxl impl SATA mode 
flags: 64bit ncg stag only ccc 
: ahci 
3ATA max UDMA/133 abar m8192Z80Qxf 0806000 port Qxf0806100 irg 2z1 
SATA link up 3.0 Gbhps (SSstatus 123 SControl 300) 
: ATA-6: VBOx HARDDISK, 1.0, max UPMAA133 
: 16777216 sectors, multi 128: LBA48 NCQ (depth 31/32) 
: Conf igured for UPpMAx133 
:0:0: Direct-ficcess ATA UBOX HARDDISK 和 有 NMST2 SS 
:DO:; [sda] 16777216 512-bute logical blocks: (8.58 GB/8.00 GiB) 
:OQ: [sda] Write Protect is off 
:QO: [sda] Write cache: enabled, read cache: enabled, doesn’t support DpPO 


sdal sdaz 
[sda] Attached SCSI disk 


加 PF 邹 自 于 | 全 园 右 ctrl | 


图 4-26 通过 环境 变量 MODALIAS 加 载 驱 动 


根据 输出 的 信息 ， 我 们 清楚 地 看 到 ， 使 用 模块 的 别名 ， 模 块 也 被 正确 
加 载 了 ， 说 明 modules.alias.bin 文 件 工作 正常 。 事 实 上 ， 通 过 文件 
modules.alias.bin 中 的 别名 和 MODALIAS 的 对 应 关系 ，modprobe 将 如 下 命 


modprobe pci:v00008086d00002829sv00000000sd00000000bc0lsc06101 


转换 为 了 : 


modprobe ahci 


4.6.8 启动 udevd 和 模拟 热 播 拔 


现在 对 于 自动 加 载 硬 盘 控 制 器 驱动 来 襄 ， 是 万 事 俱 备 ， 只 欠 东 风 了 ， 
让 我 们 来 扣 响 扳机 。 修 改 init， 在 其 中 启动 devd， 并 使 用 udevadm 对 冷 插 拔 
设备 模拟 热 插 拔 。 另 外 ，udevd 需 要 保存 某 些 运行 时 的 信息 ， 因 此 ， 我 们 需 
要 建立 run 目 录 : 


vita@baisheng:/vitas mkdir initramfs/run 


因为 这 个 目录 也 是 保存 运行 时 信息 的 ， 关 机 后 不 再 需要 保存 ， 因 此 我 
们 也 使 用 相对 高 效 的 基于 内 存 的 文件 系统 。 修 改 后 的 init 文 件 如 下 : 


Avita/r/initramfe/ init 


#!/bin/bash 

echo "Hello Linux!" 

export PATH=/usr/sbin:/usr/bin:/sbin:/bin 
mount -n -t devtmpfs udev /dev 
mount -n -t proc proc /proc 
mount -n -t sysfs sysfs /sys 
mount -n -t ramfs ramfs /run 
udevd --daemon 

udevadm trigger --action=add 
udevadm settle 

exec /bin/bash 


init 局 动 了 udev 的 服务 进程 udevd， 然 后 使 用 命令 udevadm 源 历 sysfs 中 的 
设备 ， 问 这 些 设 备 在 sysfs 文 件 系统 中 的 文件 uevent 写 入 "add" 字 符 串 ， 请 求 


内 核 重 新 发 送 KOBJ_ADD 事 件 ， 相 当 于 模拟 了 一 次 热 插 拔 。 


udevd 收 到 硬盘 控制 器 的 uevent 后 ， 将 加 载 硬 盘 控 制 器 驱动 ， 并 创建 设 
备 节 点 。 当 然 devtmpfs 也 会 创建 设备 节点 ， 但 是 udevd 与 devtmpfs 并 不 巴 
盾 ，udevd 可 以 在 devtmpfs 上 进行 用 户 空间 的 各 种 修饰 。 


命令 "udevadm settle" 的 目的 是 等 待 Wdevd 人 处理 完 内 核 生 用户 空间 发 送 的 
uevent 后 再 继续 癌 下 执行 。 否 则 ， 如 采 这 里 不 进行 等 待 ， 后 续 的 操作 有 可 能 
发 生 错误 。 举 个 例子 ， 假 如 在 udevd 正 在 调用 modprobe 加 载 便 盘 驱动 模块 
时 ，init 后 续 的 脚本 可 能 已 经 并 行 地 开始 挂 载 根 文件 系统 了 ， 但 是 此 时 设备 
尚未 被 驱动 ， 更 别提 设备 节点 了 ， 所 以 挂 载 将 会 失败 。 


重新 压缩 initramfs， 更 新 到 vita 系 统 ， 重 启 系统 。 我 们 来 检查 一 下 硬盘 
挥 制 占 是 否 正 确 加 载 ， 如 图 4-27 所 示 。 通 过 lsmod 和 查看 设备 入 点 ， 显 然 便 
盘 控 制 器 驱动 已 经 成 功 自 动 加 载 。 
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scsi 1:0:0:0: CD-ROM UBOX CD-ROM hy ee "Bs | | 
ata3: SATA livk up 3.0 Gbps (Sstatus 123 SControl 300) 

ATA-6: UBOX HARDDISK, 1.0, max UpMA/133 

1677?77?216 sectors, multi 128: LBA48 NCQ (depth 31/32) 

conf igured for UDMA/133 

HH Direct-Ahccess ATA UBOxX HARDDISK 1.9 PQ: 9 ANSI: 5 

:0: [sda] 16777216 512-bute logical blocks: (8.58 GB/8.00 GiB) 

:OQ: [sda] Write Protect is off 

:9: [sda] Write cache: enabled, read cache: enabled, doesn’t support DP0 


sda: sdal sdaz 
sd 2:0:0:0: [sda] fttached SCSI disk 
cannot set terminal process group (-1): Inappropriate ioct1l for device 
no job control in this shell 
bash-4.2# 上 tsc: Refined TSC clocksource calibration: 2382 .431 MHz 
Switching to clocksource tsc 


bash-4.2# lsmod 


Size Used bu 
1 
17049 -2 
1 ys Te 


图 对 自 钱 加 右 ctrl | 


图 4-27 查看 加 载 模块 以 及 建立 的 硬盘 设备 节点 


4.7 ” 挂 载 并 切换 到 根 文件 系统 


截止 到 目前 ， 系 统一 直 在 使 用 initramfs 作 为 临时 的 根 文 件 系统 ， 
initramfs 的 主要 目的 之 一 束 是 辅助 系统 顺利 地 切换 到 真正 的 根 文件 系 统 。 既 
然 现在 已 经 正确 的 磷 动 了 和 硬盘， 那么 接 下 来 ， 我 们 就 切换 到 硬 强 上 的 真正 
的 根 文 件 系 统 。 


4.7.1 挂 载 根 文 件 系统 


百 先 我 们 需要 确定 根 文件 系统 所 在 的 物理 介质 。 以 存储 器 为 硬盘 为 
例 ， 需 要 确定 文件 系统 储存 在 便 盘 的 哪个 分 区 。 内 核 在 引导 时 已 经 将 文件 
系统 所 在 的 介质 等 相关 参数 从 GRUB 复 制 到 了 内 核 中 ， 所 以 我 们 现在 可 以 通 
过 内 核 获 取 这 个 参数 。 谈 到 用 户 空间 与 内 核 的 通信 ， 读 者 一 定 想到 了 proc 与 
sysfs 文 件 系 统 ， 接 下 来 我 们 在 init 程 序 中 通过 proc 文 件 系统 取得 文件 系统 所 
在 的 介质 。 


在 GRUB 的 cmdline 中 ， 我 们 使 用 了 "root=/devsda2" 指 定 文件 系统 所 在 的 
介质 ， 因 此 我 们 截取 "root=" 后 面 的 值 ， 将 其 保存 在 变量 ROOT 中 ， 供 后 面 挂 
载 使 用 。 


一 般 在 准备 挂 载 文件 系统 之 前 ， 将 使 用 fsck 检 查 文 件 系 统 。 如 采 文 件 系 
统 中 存在 错误 ， 则 试图 修复 。 这 个 过 程 要 求 文件 系统 没有 被 挂 载 或 者 只 能 
以 只 读 方式 挂 载 。 因 此 ， 一 般 诈 先 以 只 读 方 式 (ro) 挂 载 根 文件 系统 ， 然 后 执 


行 fsck 检 查 修复 后 ， 再 重新 以 读 写 方式 (rw) 挂 载 。 这 也 是 大 家 看 到 的 在 
GRUB 的 配置 文件 grub.cfg 中 ， 内 核 的 命令 行 参数 要 指定 ro 的 原因 。 但 是 也 
不 排除 某 些 系统 在 司 动 时 略 过 fsck 的 步 又， 直接 将 文件 系统 以 读 写 方式 挂 
载 。 因 此 ， 在 挂 载 前 ， 我 们 首先 查看 内 核 命令 行 的 这 个 参数 。 如 采 没 有 指 
定 ， 稚 认 我 们 以 只 读 方式 挂 载 。 


对 于 文件 系统 的 类 型 ， 可 以 通过 udev 来 获取 ， 但 是 这 里 我 们 偷 个 懒 ， 
直接 让 mount 来 猜测 。 在 init 中 增加 如 下 使 用 黑体 标识 的 脚本 将 真正 的 根 文 
件 系统 挂 载 到 /mroot 目 孙 下 ， 当 然 ， 不 一 定 是 挂 载 到 /root 目 未 下 ， 也 可 以 使 用 
除了 “/” 外 的 任何 目 孙 作为 挂 载 点 。 


/vita/initramfs/init 


#!/bin/bash 

echo "Hello Linux!" 

export PATH=/usr/sbin:/usr/bin:/sbin:/bin 
export ROOTMNT=/root 

export ROFLAG=-r 

mount -n -t devtmpfs udev /dev 
mount -n -t proc proc /proc 
mount -n -t sysfs sysfs /sys 
mount -n -t ramfs ramfs /run 
udevd --daemon 

udevadm trigger --action=add 
udevadm settle 


for x in $(cat /proc/cmdline); do 
case $x in 
root=*) 
ROOT=${x#root=} 


os 
|- 呈 


ro) 
ROFLAG=-r 
rw) 
ROFLAG=-w 
;7? 
esac 
done 


mount ${ROFLAG} ${ROOT} ${ROOTMNT} 


exec /bin/bash 


使 用 修改 的 iniramfs 重 新 启动 vita 系 统 ， 查 看 mount 的 输出 和 /root 目 好 下 
的 内 容 ， 确 定 真 正 的 根 文件 系统 是 否 已 经 挂 载 ， 如 图 4-28 所 示 。 根 据 mount 
命令 的 输出 可 见 ， 分 区 "/dev/sda2" 确 实 被 挂 载 到 了 "root" 目 录 下 ， 该 目录 下 
也 不 再 是 个 空 目 录 了 ， 古 根 文件 系统 的 内 容 。 
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[sda] Write Protect is of 
[sda]l Write cache: enabled，read cache: enabled，doesnm' t supbort DPD 


[sda] httached SCSI disk 
ExT4-fs (sdaz};: INFO: recovery reduired on readonly filesystem 
ExT4-fs (sda2z): write access will be enabled during recovery 
ExT4-fs (sda2): recovery complete 
ExT4-fs (sdae)});: mounted filesystem with ordered data mode. Opts; (null) 
cannot set terminal process group (-1): Inappropriate ioctl for device 
no job control in this shell 
-4.2# tsc;: Refined TSC clocksource calibration: 2382 .461 MHz 
SIMD A Tl tscC 


bash-4.2# mount 
rootfs on ~ type rootfs (rw) 
idev on /dev type devitmpfs (rw,relatime,mode=Q?55) 
proc on /proc type proc (rw,relatime) 
syusfs on /sys type sysfs (rw,relatime) 
ramfs on /run type ramfs (rw,relatime) 
dev/sdaz on root type ext4 (ro,relatime,data=ordered) 
bash—4 .2# 
4 lh Ye 
boot etc lib proc rootfs.tgz sbin sys usr var 


习 儿 男 国 生 | 多 团 右 Ctrl | 


图 4-28 目 动 挂 载 根 文件 系统 成 功 


4.7.2 ”切换 到 根 文件 系统 


真正 的 根 文件 系统 已 经 被 挂 载 『， 我 们 接 下 来 束 要 切换 到 真正 的 根 文 
件 系 统 


initramfs 中 的 这 个 init 脚 本 也 完成 了 它 的 历史 使 命 ， 该 退出 舞台 了 。 系 
统 的 第 一 个 进程 应 该 使 用 根 文件 系统 中 的 一 个 程序 了 。 无 论 是 SystemV 还 是 
systemd， 都 会 提供 一 个 init 程 序 ， 通 常 这 个 程序 都 是 使 用 二 进 制 格式 的 。 但 
是 这 里 ， 我 们 为 了 不 把 事情 搞 得 太 复杂 ， 真 正 的 用 户 空 间 的 init 程 序 依 然 使 
用 shell 脚 本 。 一 般 而 言 ，init 存 储 在 /sbin 目 录 下 ， 所 以 需要 在 根 文件 系统 中 
建立 /sbin 目 录 。 


vita@baisheng:/vita/rootfs$ mkdir sbin 


init 脚 本 简单 的 执行 一 个 交互 式 的 bash 。 


/vita/rootfestabDin/inits 


#!/bin/bash 
exec /bin/bash 


最 后 注意 将 该 程序 加 上 可 执行 权限 


/vita/rootfes/sblins chmod artx lnit 


根 文 件 系 统 准 备 好 后 ， 接 下 来 开始 同根 文件 系统 切换 ， 步 又 如 下 : 


1) 删除 rootfs 文 件 系统 中 不 再 需要 的 内 容 ， 释 放 内 存 空间 。 


现在 挂 载 在 “/* 下 的 rootfs 中 的 内 容 是 initramfs 解 压 来 的 ， 在 我 们 准备 把 
磁盘 文件 系统 挂 载 到 “” 前 ， 需 要 删除 rootfs 中 的 内 容 ， 以 释放 其 占用 的 内 存 


空间 。 但 是 ， 在 删除 rootfs 前 ， 我 们 需要 : 


争 停 止 正在 运行 的 进程 ， 这 里 就 是 udevd 


令 将 /dev、/run、/proc 和 /sys 目 录 移 动 到 真正 的 文件 系统 上 。 因 此 ， 需 
要 在 根 文件 系统 上 建立 如 下 目录 : 


vita@baisheng:/vita/rootfs$ mkdir sys proc dev run 
2) 将 根 文件 系统 从 "/root" 移 动 %/” 下 。 


3) 更 改进 程 的 文件 系统 namespace， 使 其 指向 真正 的 根 文件 系统 。 
为 当前 进程 加 是 进程 1， 而 后 续 进 程 都 是 从 进程 1 复制 的 ， 所 以 后 续 进 程 的 
文件 系统 的 namespace 自 然 束 是 使 用 的 真正 的 根 文 件 系 统 。 


4) 运行 真正 的 文件 系统 中 的 "init" 程 序 。 


这 里 提 一 个 问题 ， 前 面 的 几 个 动作 还 可 以 用 脚本 继续 实现 吗 ? 单个 动 
作 本 身 没 有 问题 ， 但 是 不 知道 读者 留意 到 没有 ， 一 旦 步 又 1) 执行 了 ，rootfs 
中 吏 没 有 内 容 了 ， 因 此 后 面 步骤 中 使 用 的 命令 已 经 不 在 了 ， 被 删除 了 ， 何 
谈 步 又 2) 和 步骤 3) ? 因此 ， 这 里 我 们 使 用 一 个 小 技巧 ， 将 上 面 的 步骤 都 


封装 到 一 个 二 进 制 程序 中 ， 将 这 个 程序 加 载 进 内 存 后 ， 我 们 再 删除 rootfs 中 
的 内 容 ， 如 此 一 来 ， 步 骤 2) 和 步骤 3) 都 得 以 顺利 完成 。 这 个 程序 源码 如 
下 : 


switch root.c: 


#include <errno.h> 
#include <dirent.h> 
#include <sys/stat.h> 
#include <stdio.h> 
#include <stdlib.h> 
#include <sys/mount.h> 
#include <fcntl.h> 
#include <unistd.h> 


int delete dir(char *directory); 


void delete (char *what) 
{ 
if (unlink(what)) { 
if (errno == EISDIR) { 
if (!delete dir(what)) 
rmdir (what); 


} 


int delete dir(char *directory) 
DIR: wadlrs 
struct dirent *d; 
Struct stat: BtLyp Bt 人 2 


char path [PATH MAX]; 


if (lstat (directory, &st1)) 
return errno; 


if (!(dir = opendir(directory))) 
return errno; 


while ((d = readdir(dir))) { 
fe ELS sh wi 
if {(d->d name[0] == '.' && 
(d->d name[1] == '\0' | 
(d->d name[1] == 1. && d->d name[2] == '\0'))) 
continue; 


sprintf (path, "%s/%s", directory, d->d name); 
lstat (path, &st2); 
/* do not recurse down mountpoint avoiding del realroot */ 
if (st2.st dev != stl.8t dev) 
continue; 


delete (Path) ; 


} 


closedir (dir); 
return 0; 


int main(int argc, char *argv[]) 
int console fd; 


/* change to the new root directory */ 
chdir(argv[1]); 


/* delete rootfs contents */ 
delete dir("/"); 


/* overmount the root */ 
mount (Tm, wv/", NULT， MS_MOVE, NULL); 


/* chroot, chadir */ 
Chroot(™., My 
chair("/"); 


/* open /dev/console */ 

console fd = open("/dev/console'", O RDWR); 
dup2 (console fd, 0); 

dup2 (console fd, 1); 

dup2 (tonsole fd, 2); 

close (console fd); 


/* spawn init */ 
execlp(largv[2], argv[2], NULL); 


return 0; 


} 


Makefile 文 件 如 下 : 


Switeh oot: wkEcn rootwe; 
clean: 


BH EE “a 
rm or SWLICCh Look 


switch_root 本 身 的 逻辑 比较 简单 ， 基 本 就 是 执行 我 们 上 面 的 步 又 1) ~ 步 


又 4) ， 首 先 切 换 到 新 的 文件 系统 ， 因 此 后 面 的 “.” 束 是 在 新 文件 系统 中 ， 然 
后 使 用 chroot 命 令 ， 将 “.” 作 为 新 的 根 文 件 系 统 ， 完 成 进程 的 文件 系统 
namespace 的 切换 ， 并 重 定向 了 stdio、stdout 和 stderr。 其 中 有 一 处 需要 特别 


， 距 是 在 执行 删除 前 ， 和 需要 做 一 个 小 的 判断 ， 以 免 把 挂 载 在 


${ROOTMNT} 下 的 真正 的 文件 系统 也 删除 了 。 


编译 后 ， 将 switch_root 复 制 到 initramfs: 


vita@baisheng:/vita/build/switch root$ cp Switch root \ 
/vita/inieramtsBrny 


修改 initramfs 中 的 init 脚 本 如 下 : 


ET 


#!/bin/bash 

echo "Hello Linux!" 

export PATH=/usr/sbin:/usr/bin:/sbin:/bin 
export ROOTMNT=/root 

export ROFLAG=-Ir 

mount -n -t devtmpfs udev /dev 
mount -n -t proc proc /proc 
mount -n -t sysfs sysfs /sys 
mount -n -t ramfs ramfs /run 
udevd --daemon 

udevadm trigger --action=add 
udevadm settle 


fo6r x in St{teat /proce/emdline)y d6 
case $x in 
EGOtSS) 
ROOT=$ {x#root=} 


» 
0 


ro) 
ROFLAG= - 工 
人 
rw) 
ROFLAG=-W 
esac 


done 


mount ${ROFLAG} ${ROOT} S${ROOTMNT } 


# Stop udevd 

udevadm control --exit 

# Move to the real filesystem 

mount -n --move /dev ${ROOTMNT}/dev 
mount -n --move /run ${ROOTMNT}/run 
mount -n --move /proc ${ROOTMNT}/proc 
mount -n --move /sys ${ROOTMNT}/sys 


switch root ${ROOTMNT} /sbin/init 


最 后 ， 为 了 验证 是 否 已 经 切换 到 根 文件 系统 了 ， 我 们 在 rootfs 中 安装 两 
个 程序 cat 和 1s: 


vita@baisheng:/vitas$ cp sysroot/usr/bin/cat rootfs/bin/ 
vita@baisheng:/vitas$ cp sysroot/usr/bin/ls rootfs/bin/ 


用 修改 过 的 根 文件 系统 和 initramfs 更 新 vita 系 统 ， 然 后 重新 局 动 vita 系 
。 使 用 命令 cat 打 印 文件 /procmounts 的 内 容 ， 如 图 4-29 所 示 。 


11.10 [正在 运行 ] - Dracle VM VirtualBox 


conf igured for UDMA/133 
. ATA UBOX HARDDISK i ES 
[sda] 1677?7?216 Siz-byte logical blocks: (8.58 GB/8.00 GiB) 
[sda] Write Protect is off 
[sda] Write cache: enabled, read cache: enabled, doesn’t support DPO 


: [sda] httached SCSI disk 
EXT4— 了 (sdaz): mounted filesystem with ordered data mode. Opts: (null) 
: Ref ined TSC clocksource calibration: 2380.562 MHz 
Switching to clocksource tsc 
cannot set terminal process group (-1): Inappropriate ioctl for device 


no job control in this shell 
1 3 ls .2 间 
bash-4.2# cat -procmounts 
rootfs / rootfs rw 0 0 
idev dev devitmpfs rw,relatime,mode=07?55 0 0 
proc /proc proc rw,relatime © 0 
Usfs -SUS SUSfS rwrelatime OO 
ramfs /run ramfs rw relatime OQ 0 
dev/sda2 / ext4 ro,relatime,data=ordered 0 0 


boot dew lib proc rootfs.tygz run sbin ys 


习 帮 时 国生 


9 团 右 ctrl 


图 4-29 成 功 切 换 到 根 文 件 系 统 


根据 /proc/mounts 的 输出 可 见 ， 存 放 根 文件 系统 的 分 区 "/dev/sda2" 已 经 
挂 载 到 了 “/” 下 “。 在 这 里 ， 我 们 也 看 到 ，rootfs 还 是 作为 整个 虚拟 文件 系统 的 
根 存 在 的 。 


第 5 章 ”从 内 核 空间 到 用 户 空 间 


前 面 ， 我 们 从 无 到 有 ， 编 译 了 内 核 ， 构 建 了 initramfs 和 一 个 基本 的 根 文 
件 系统 ， 成 功 局 动 了 用 户 空 间 的 第 一 个 进程 。 虽 然 我 们 只 是 迈 出 了 一 小 
步 ， 但 是 这 是 关键 的 一 步 。 在 此 基础 上 ， 我 们 可 以 放 开 手脚 ， 去 探索 曾经 
的 遥 不 可 及 。 但 是 ， 我 们 也 才刚 刚 破冰 ， 学 而 不 思 则 赔 ， 因 此 ， 在 继续 构 
建 一 个 完整 的 操作 系统 之 前 ， 我 们 先 来 更 深入 的 探索 一 下 这 一 切 是 如 何 发 
3 


曾经 不 止 一 次 ， 笔 者 在 各 个 技术 文章 、 书 籍 、 甚 至 顶尖 高 校 的 讲义 
中 ， 都 看 到 类 似 的 论述 : 内核 首 先进 入 实 模 式 ， 然 后 从 实 模式 跳 入 保护 模 
式 ， 事 实 果 真如 此 吗 ? 在 这 一 章 中 ， 我 们 首先 从 Linux 操 作 系统 的 加 载 谈 
起 。 


对 于 普通 程序 ， 它 们 运行 在 操作 系统 已 经 为 其 准备 好 的 环境 中 ， 操 作 
系统 则 没有 这 么 答 运 ， 其 运行 在 裸 机 上 “。 操 作 系统 需要 在 襟 机 上 目 己 引导 
自己 ， 而 且 还 要 为 运行 进程 搭建 好 环境 。 因 此 ， 本 章 的 5.2 节 和 5.3 节 将 讨论 
内 核 是 如 何 目 解压 以 及 如 何 初始 化 的 。 


操作 系统 最 终 的 目的 之 一 是 承载 进程 。 因 此 ， 在 本 章 的 最 后 ， 我 们 讨 
论 了 进程 的 加 载 和 运行 。 提 及 进程 的 加 载 和 运行 ， 我 们 几乎 将 所 有 的 关注 
都 放 在 了 内 核 上 ， 却 往往 忽略 了 男 外 一 个 为 进程 辅 以 建立 运行 环境 的 重要 
角色 : 动 仿 链接 右 。 在 进程 加 载 中 ， 相 当 一 部 分 烦琐 而 又 重要 的 工作 由 动 


态 链 接 器 完成 。 因 此 ， 除 了 讨论 进程 在 内 核 中 的 加 载 过 程 外 ， 我 们 也 深入 
探讨 了 进程 在 用 户 空 间 的 加 载 和 链接 过 程 。 


5.1 Linux 操 作 系 统 加 载 


PC 上 电 或 复位 后 ， 处 理 器 跳 转 到 BIOS， 开 始 执行 BIOS。BIOS 首 先进 
行 加 电 自 检 ， 初 始 化 相关 硬件 ， 然 后 加 载 MBR 中 的 程序 到 内 存 0x7c00 处 并 
跳 转 到 该 地 址 处 ， 接 着 由 MBR 中 的 程序 完成 操作 系统 的 加 载 工 作 。 通 常 ， 
MBR 中 的 程序 也 被 称 为 Bootloader。 当 然 ， 鉴 于 现代 操作 系统 的 复杂 性 ， 
Bootloader 已 远 远 不 止 一 个 忆 区 大 小 。 这 一 节 ， 我 们 就 以 一 个 具体 的 
GRUB 为 例 ， 探 讨 操 作 系统 的 加 载 过 程 。 为 简单 起 见 ， 我 们 
只 讨论 典型 的 从 硬盘 加 载 操 作 系 统 的 过 程 ， 所 以 后 续 的 讨论 全 部 是 针对 从 
硬盘 启动 的 情况 。 


Bootloader 


PC 上 硬 如 的 传统 分 区 方式 是 MBR 分 区 方案 。 但 是 MBR 最 大 能 表示 的 分 
区 大 小 为 2TB。 因 此 ， 随 着 硬盘 容量 的 不 断 扩 大 ， 为 了 突破 MBR 分 区 方式 
的 一 些 限制 ，20 世 纪 90 年 代 Intel 提 出 了 GPT 分 区 方案 。 对 于 不 同 的 分 区 方 
式 ， 加 载 操作 系统 的 方式 还 是 有 些许 不 同 的 。 也 是 为 了 简单 起 见 ， 我 们 结 
合 现在 依然 广泛 使 用 的 传统 的 MBR 分 区 方案 进行 讨论 。 


5.1.1 ” GRUB 了 映像 构成 


对 于 仅 有 512 字 市 大 小 的 MBR， 双 要 留 给 分 区 表 64 子 广 ， 在 这 么 小 的 一 
个 空间 ， 已 经 很 难 容纳 加 载 一 个 现代 操作 系统 的 代码 。 于 是 GRUB 采 取 了 分 


阶段 的 策略 ，MBR 中 仅 存放 GRUB 的 第 一 阶段 的 代码 ，MBR 中 的 代码 负责 
把 GRUB 的 其 余部 分 载 入 内 存 。 


但 是 GRUB 分 成 几 段 合适 呢 ? 要 回答 这 个 问题 我 们 还 得 从 DOS 谈 起 。 


DOS 的 系统 映像 是 不 能 路 柱 面 存放 的 ， 所 以 在 DOS 时 代 ， 磁 盘 的 第 一 
个 分 区 索性 并 没有 紧 接 在 MBR 的 后 面 ， 而 是 直接 从 下 一 个 柱 面 的 边界 开 
始 。 而 且 ， 按 照 柱 面 对 齐 ， 对 系统 的 性 能 有 很 大 好 处 ， 这 对 于 现代 操作 系 
统 同 样 适用 。 于 是 ， 在 MBR 与 第 一 个 分 区 之 间 ， 丈 出 现 了 一 块 空 区 域 。 
从 那 时 起 ， 这 种 分 区 方式 成 为 了 一 个 约定 俗 成 ， 基 本 上 所 有 的 分 区 工具 都 
把 这 种 分 区 方式 保留 了 下 来 。 如 果 硬 强 是 MBR 分 区 方案 ， 用 分 区 工具 fdisk 
束 可 以 看 到 这 一 点 ， 以 笔者 的 机 絮 为 例 : 


root@baisheng:~# fdisk -1 


Disk /dev/sda: 500.1 GB, 500107862016 bytes 
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 ... 


Device Boot Stark End Blocks Id System 


/dev/sdal 党 63 104872319 52436128+ 83 Linux 
/dev/sda?2 104872320 188779814 41953747+ 83 Linux 


根据 fdisk 的 输出 可 见 ， 每 个 磁道 划分 为 63 个 忆 区 。 便 强 的 第 一 个 分 区 
起 始 于 第 63 个 硝 区 (从 0 开始 计数 ) 。 也 就 是 说 ， 对 于 第 0 个 磁道 ， 除 了 
MBR 占据 的 一 个 分 区 ， 其 余 62 个 分 区 是 空 几 的 。 


于 是 ，GRUB 的 开发 人 员 就 打算 把 GRUB* 典 入 ”到 这 个 空 亲 区域， 这 样 
做 的 好 处 就 是 相对 来 说 比较 安全 。 因 为 某 些 文件 系统 的 一 些 特性 或 者 一 些 
修复 文件 系统 的 操作 ， 有 可 能 导致 文件 系统 中 的 文件 所 在 的 扇 区 发 生 改 


变 。 因 此 ， 单 纯 依靠 司 区 定位 文件 是 有 一 定 的 风险 的 。 而 对 于 GRUB 来 说 ， 
在 其 初始 阶段 ， 由 于 尚未 加 载 文 件 系 统 的 驱动 ， 因 此 ， 它 恰恰 需要 通过 
BIOS 以 而 区 的 方式 访问 GRUB 的 后 续 的 阶段 。 但 是 ， 一 旦 GRUB 般 入 到 这 个 
不 属于 任何 分 区 的 特殊 区 域 ， 则 将 不 再 受 文件 系统 的 影响 。 当 然 将 GRUB 诅 
入 到 这 个 区 域 也 不 是 必须 的 ， 但 是 因为 这 个 相对 安全 的 原因 ，GRUB 的 开发 
人 员 推 荐 将 GRUB 扒 入 到 这 个 区 域 。 


但 是 这 个 区 域 的 大 小 是 有 限 的 ， 通 常 ， 一 个 扇 区 512 字 节 ， 一 个 柱 面 最 
多 包含 63 个 扇 区 。 因 此 ， 除 去 MBR， 这 个 区 域 的 大 小 是 62 个 扇 区 ， 即 
31KB。 因 此 ， 磐 入 到 这 里 的 GRUB 的 映像 最 大 不 能 超过 31KB。 为 了 控制 蔡 
入 到 这 个 区 域 中 的 映像 的 尺寸 不 超过 31KB，GRUB 采 用 了 模块 化 的 设计 方 


案 。 


GRUB 在 仍 入 的 映像 中 包含 硬件 及 文件 系统 的 张 动 ， 因 此 ， 一 旦 众 入 的 
映像 载 入 内 存 ，GRUB 即 可 访问 文件 系统 。 其 他 模块 完全 可 以 存储 在 文件 系 
统 上 ， 通 过 文件 系统 的 接口 访问 这 些 模块 ， 避 开 了 因为 如 修复 文件 系统 而 
引起 文件 所 在 局 区 的 变化 而 市 来 的 风险 。 男 外 也 可 以 很 好 地 控制 钥 入 到 空 
朵 扇 区 的 映像 的 玉 寸 。 


由 上 壕 内 容 可 知 ，GRUB 将 映像 分 为 三 个 部 分 : MBR 中 的 bootimg、 报 
入 空闲 忆 区 的 core.img 以 及 存储 在 文件 系统 中 的 模块 。 这 三 个 部 分 也 对 应 着 
GRUB 执 行 的 三 个 阶段 。 在 MBR 分 区 模式 下 ， 以 舱 入 方式 安装 的 GRUB 的 各 
个 部 分 在 硬盘 上 的 分 布 如 图 5-1 所 示 。 


boot.img core.img modules ; modules 
(stage 1) (stage 2) :(stage 3-1): :(stage 3-2): 


OO 


1 sector 62 sectors Partition 1 
(MBR) 


图 5-1 在 MBR 分 区 模式 下 以 巷 入 方式 安装 的 GRUB 


boot.img 以 及 core.img 分 别 以 读 写 磁盘 局 区 的 方式 访问 ， 它 们 不 属于 任 
何 一 个 人 硬 副 分 区 ， 所 以 不 会 受到 文件 系统 的 影响 。 第 三 阶段 的 这 些 模块 是 
存储 在 文件 系统 上 的 ， 虽 然 文件 所 在 的 忆 区 可 能 会 变动 ， 但 是 GRUB 不 再 通 
过 扇 区 访问 而 是 通过 文件 系统 访问 。 


1.MBR 有 映像 


boot.img 主 要 功能 是 将 core.img 中 的 第 一 个 悄 区 载 和 内存 。 为 什么 只 是 
加 载 core.img 的 第 一 个 而 区 而 不 是 加 载 整个 core.img 呢 ? 答案 还 是 因为 那 可 
怜 的 区 区 512 字 市 ， 除 去 64 字 市 的 分 区 域 表 信 息 以 及 最 后 的 2 字 广 的 引导 标 
识 ， 还 要 给 BIOS 保 留 一 段 参数 空间 ，boot.img 中 可 用 的 空间 已 经 被 瓜分 得 所 
和 独 无 几 。 因 此 ， 索 性 boot.img 中 仪 记录 core.img 的 第 一 个 司 区 号 ， 并 仪 将 这 
个 书 区 号 对 应 的 忆 区 中 的 内 容 加 载 入 内 存 ，core.img 其 余部 分 的 加 载 留 给 
core.img 的 第 一 个 司 区 的 代码 去 考虑 吧 。 


bootimg 对 应 的 源 文件 是 boot,S， 其 中 保存 core.img 的 第 一 个 而 区 的 位 置 
如 下 : 


grub-2.00/grub-core/boot/i386/pc/boot.s: 


. = start + GRUB BOOT MACHINE KERNEL SECTOR 
Kernel sector: 
.long 和 


grub-2.00/include/grub/i386/pc/boot.h.: 
#define GRUB BOOT MACHINE KERNEL SECTOR 0x5c 


boot.S 中 标号 kernel_sector 所 在 处 ， 即 boot.img 中 偏 移 
GRUB_BOOT_MACHINE_KERNEL_SECTOR， 即 92 字 节 (0x5c) 处 ， 记 录 
的 就 是 core.img 第 一 个 请 区 在 硬盘 上 所 在 的 硬 区 号 。 后 面 讨 论 GRUB 安 装 
时 ， 我 们 会 看 到 ， 在 安装 GRUB 时 ，GRUB 的 安装 程序 将 根据 core.img 的 第 
一 个 而 区 占据 的 实际 硬盘 扇 区 号 修改 这 里 。 事 实 上 ， 如 果 GRUB 采 用 的 是 竺 
入 模式 ， 那 么 这 里 的 扇 区 就 应 该 是 1， 即 紧 接 在 MBR 后 面 的 一 个 扇 区 。 


由 于 程序 大 小 被 限制 在 可 怜 的 一 个 而 区 内 ， 不 能 奢望 在 这 么 小 的 程序 
内 实现 硬盘 以 及 文件 系统 的 驱动 ， 所 以 ，boot.img 只 能 利用 BIOS 提 供 的 中 断 
癌 量 为 0x13 的 基于 届 区 的 磁 副 读 写 服务 。 以 支持 LBA 模 式 的 硬盘 为 例 ， 
取 扇 区 的 代码 如 下 : 


grub-2.00/grub-core/boot/i386/pc/boot.s: 


lba mode: 


movl kernel sector, Sebx 
movb SOx42, 多 ah 
二 ‘SONLS 


/* boot kernel */ 
]mp * (Kernel address) 


boot.img 按 照 BIOS 服 务 的 有 要求， 设置 相应 的 寄存 器 ， 调 用 BIOS 服 务 。 
BIOS 负 责 将 地 址 kernel_sector 处 指示 的 书 区 号 所 在 而 区 的 内 容 载 入 内 存 。 
boot.img 最 后 把 读 入 的 局 区 内 容 移动 到 符号 kernel_address 处 指示 的 地 址 ， 并 
跳 转 到 那里 执行 。 符 号 kernel address 处 的 值 为 安 
GRUB_BOOT_MACHINE_KERNEL_ADDR， 如 下 代码 : 


grub-2.00/grub-core/boot/i386/pc/boot.s: 


kernel address: 
.word GRUB BOOT MACHINE KERNEL ADDR 


这 个 宏 的 值 是 0x8000， 也 就 是 说 ，GRUB 第 二 阶段 映像 被 移动 到 了 这 
里 ， 并 且 从 这 里 继续 执行 。 后 面 在 讨论 GRUB 启 动 时 ， 读 者 会 看 到 ， 链 接 器 
给 core.img 的 最 初 512 字 布 分 配 的 地 址 ， 也 确实 是 从 0x8000 开 始 的 。 


另外 ， 读 者 并 不 会 在 boot.S$ 中 看 到 关于 分 区 表 的 部 分 ， 因 为 在 安装 
GRUB 时 ， 安 装 程 序 负 责 将 分 区 表 写 到 boot'img 中 。 


2.GRUB 核 心 映像 


core.img 包 括 多 个 映像 和 模块 ， 以 从 硬盘 启动 为 例 ，core.img 包 含 的 内 
容 如 图 5-2 所 示 。 


uncompressed 
i 
diskboot lzma_decom kernel.img biosdisk |part msdos exitd| Oemmdds 
,Img press.img mod mod 
\ 
1 sector compressed 


图 5-2 core.img 构 成 示意 图 


图 5-2 中 diskboot.img 占 据 core.img 中 的 第 一 个 而 区 ， 它 就 是 boot.img 加 载 
的 core.img 的 所 请 的 第 一 个 局 区 。diskboot.img 用 来 加 载 core.img 中 除 
diskboot.img 外 的 其 余部 分 ， 与 boot.S 的 实现 本 质 上 并 无 不 同 ， 也 是 借助 
BIOS 的 中 断 服 务 。 只 不 过 bootimg 加 载 一 个 面 区 进入 内 存 ， 而 diskboot,img 
加 载 多 个 忆 区 进入 内 存 而 已 。 


与 boot.img 类 似 ，diskboot.img 也 需要 知道 core.img 的 后 续 部 分 所 在 的 局 
区 。 显 然 ， 只 有 在 将 GRUB 安 装 到 磁盘 时 ， 才 能 知道 core.img 实 际 所 占据 的 
忆 区 。 因 此 ， 在 安装 时 ，GRUB 的 安装 程序 会 将 core.img 占 据 的 请 区 号 写 入 
diskboot.img 中 。 相 关 代 码 如 下 : 


grub-2.00/grub-core/boot/i386/pc/diskboot.s: 


.= Start + 0x200 - GRUB BOOT MACHINE LIST SIZE 
LOCAL (firstlist): 
blocklist default start: 


EC 2 0 
blocklist default len: 
.word 0 


blocklist default seg: 
.word (GRUB BOOT MACHINE KERNEL SEG + 0x20) 


diskboot.img 的 最 后 12 字 市 记录 的 是 一 个 blocklist， 每 个 blocklist 代 表 一 
个 连续 的 而 区 ， 其 对 应 的 C 语 言 的 结构 体 如 下 : 


grub-2.00/include/grub/offsets.h: 


Struct gEub pe: bio boot DIGGKLLSE 


{ 


grub LE64 t starty 
grub LEL6 Ler 
grub uint16 七 segment.; 
} _attribute  ((packed)); 


其 中 start 代 表 这 个 连续 的 局 区 的 起 始 悄 区 ，len 表 示 局 区 的 数量 ， 
segment 表 示 户 区 加 载 到 内 存 的 段 地 址 。 


在 diskboot.S 中 ， 注 意 标号 blocklist_default_seg 处 的 宏 
GRUB_BOOT_MACHINE_KERNEL_SEG， 这 是 一 个 类 似 带 参数 的 宏 ， 对 
于 使 用 x86 架 构 的 PC，MACHINE 最 后 会 被 替换 为 "1386_PC"， 展 开 后 为 
GRUB_BOOT_1386_PC_KERNEL_SEG: 


grub-2.00/include/grub/offsets.h: 


#define GRUB BOOT I386 PC KERNEL SEG 0x800 


也 就 是 说 ，diskbootimg 将 core.img 中 除 diskboot.img 外 的 部 分 加 载 到 内 
存 的 段 地 址 为 0x820。 在 diskboot.img 进 行 加 载 时 ， 将 段 内 偏 移 设 置 为 了 0， 
所 以 最 终 core.img 的 其 余部 分 被 加 载 到 了 从 内 存 地 址 0x8200 开 始 的 地 方 。 在 
前 面 讨论 boot.img 时 ， 我 们 看 到 ，boot.img 将 diskboot.img 加 载 到 了 0x8000 
处 。 也 区 是 说 ，diskbootimg 正 好 占据 了 一 个 而 区 (0x200 字 节 ) 。 


事实 上 ， 对 于 MBR 分 区 方案 ， 如 果 采 用 了 藤 入 式 的 安装 方式 ， 那 么 只 
要 有 一 个 blocklist 就 足够 了 。 当 使 用 非 散 入 式 的 安装 方式 时 ，core.img 可 能 
被 分 块 存储 在 人 确 盘 上 ， 因 此 ，diskboot.img 中 可 能 存在 多 个 blocklist， 每 一 个 
blocklist 代 表 一 段 连续 的 局 区 。 第 一 个 blocklist 位 于 diskboot.img 的 最 后 ， 
增加 一 个 blockllist， 问 着 diskboot.img 开 始 的 方 同 延伸 。 


为 了 控制 core.img 的 体积 ，GRUB 将 core.img 进 行 了 压缩 。 显然 
diskboot.img 是 不 能 压缩 的 ， 因 为 boot.img 中 没有 任何 解压 代码 。 因 此 ， 
GRUB 只 将 core.img 中 的 kernel.img 和 模块 进行 了 压缩 。 对 于 基于 x86 架 构 的 
PC，GRUB 默 认 使 用 的 是 lzma 压 缩 算 法 。 当 然 安 装 GRUB 前 创建 core.img 
时 ， 用 户 也 可 通过 命令 行 参 数 指定 压缩 算法 ， 但 是 从 2.0 版 本 的 代码 来 看 ， 
对 于 x86 架 构 来 说 ， 只 能 使 用 lzma 压 缩 算法 。 


既然 有 压缩 部 分 ， 就 要 有 人 负责 解压 的 部 分 。GRUB 将 lzma 算 法 的 解压 缩 
代码 编译 为 lzma_decompress.img， 连 接 在 diskboot.img 的 后 面 。diskboot.img 


将 core.img 加 载 进 内 存 后 ， 将 跳 转 到 lzma_decompress.img， 执 行 其 中 代码 解 
压缩 core.img 后 面 的 压缩 部 分 。 下 面 的 代码 就 是 diskboot.img 加 载 完 core.img 
后 进行 的 跳 转 : 


grub-2.00/grub-core/boot/i386/pc/diskboot.s: 


LOCAL (bootit): 


ljmp $0, $(GRUB BOOT MACHINE KERNEL ADDR + 0x200) 


宏 GRUB_BOOT MACHINE_KERNEL _ADDR 定 义 如 下 : 


#define GRUB BOOT MACHINE KERNEL ADDR 
(GRUB BOOT MACHINE KERNEL SEG << 4) 


刚刚 我 们 已 经 看 到 了 ， 宏 GRUB_BOOT_MACHINF_KERNEL_SEG 值 
为 0x800， 于 是 左 移 4 位 后 ， 宏 GRUB_BOOT_MACHINE_KERNEL_ADDR 
的 值 为 0x8000。 可 见 ， 加 载 完 core.img 剩 余部 分 后 ，diskbootimg 跳 转 到 了 地 
址 0x8000+0x200 处 ， 正 是 lzma_decompress.img。1lzma_decompress.img 解 压 
后 面 的 压缩 的 映像 ， 最 终 跳 转 到 kernel.img 。 


根据 其 名 字 我 们 就 可 以 猜 到 了 ，kernel.img 是 GRUB 的 核心 代码 了 。 其 
中 包括 为 底层 具体 的 磁 强 驱动 以 及 文件 系统 张 动 提供 公共 的 服务 层 。 
kernelimg 的 主 入 口 画 数 是 grub_main。1lzma_decompress.img 解 压 后 正 是 跳 转 
到 这 个 函数 ， 从 某 种 意义 上 讲 ， 这 里 才 是 GRUB 的 真正 开始 。 


grub-2.00/grub-core/kern/main.c: 


void attribute  ((noreturn)) grub main (void) 


| 


grub load _ modules () ; 


鉴于 舱 入 区 域 的 尺寸 有 限 ， 因 此 只 有 最 关键 的 模块 才能 包含 到 core.img 
中 ， 随 着 core.img 一 起 嵌入 到 MBR 后 面 的 空闲 扇 区 。 那 么 哪些 模块 是 关键 模 
块 昵 ? 只 有 core.img 文 持 文件 系统 ， 它 才 可 以 读 入 其 他 模块 。 所 以 ， 这 就 是 
磁盘 驱动 模块 biosdisk.mod、MBR 分 区 模式 模块 part_msdos.mod 以 及 文件 系 
统 的 驱动 模块 ext2.mod (虽然 其 名 字 为 ext2， 但 是 这 个 模块 支持 EXT 系 列 文 
件 系 统 ) 包含 到 core.img 中 的 原因 ， 它 们 的 目的 是 驱动 文件 系统 。 


这 几 个 模块 虽然 已 经 被 diskboot.img 加 载 进 了 内 存 ， 但 是 显然 只 是 将 它 
们 简单 地 “ 放 到 ”内 存 中 还 古 不 够 的 ， 因 为 这 些 模块 就 相当 于 日 标 文 件 ， 指 
令 和 数据 地 址 都 是 从 0 开始 分 配 的 ， 比 如 以 笔者 机 器 上 的 GRUB 的 模块 
ext2.mod 为 例 : 


root@baisheng:/boot/grub/i386-pc# readelf -S ext2.mod 


Section Headers: 


[Nr] Name Type Addr Oh Size 
LE 而 NULL 00000000 000000 000000 


[ 2] xatext PROGBITS 00000000 000034 000cb7 


所 以 需要 为 它们 进行 重 定位 ， 还 是 以 这 个 模块 为 例 ， 我 们 可 以 看 到 其 
有 大 量 需要 重 定 位 的 符号 : 


root@baisheng:/boot/grub/i386-pc# readelf -r ext2.mod 


Relocation section '.rel.text' at offset 0x1330 contains 101 
Offset Info Type Sym.Value Sym. Name 
0000000a 00001702 R 386_PC32 00000000 grub free 


Relocation section '.rel.data' at offset 0x1658 contains 8 entries: 
Offset Info Type Sym.Value Sym. Name 
00000008 00000201 R 386_ 32 00000000 rodatastrlisLl 


5.1.2 ”安装 GRUB 


通常 ， 在 安装 操作 系统 的 最 后 ， 操 作 系 统 安装 程序 将 会 为 用 户 安装 
GRUB。 当然 ， 有 时 我 们 也 会 手动 安装 GRUB。 但 是 都 是 通过 GRUB 提 供 的 
工具 ， 执 行 的 命令 如 下 : 


grub-install /dev/sda 


事实 上 ， 在 这 个 安装 命令 的 背后 ，GRUB 的 安装 过 程 分 为 两 个 阶段 ， 第 
一 阶段 是 创建 core.img，GRUB 为 此 提供 的 工具 是 grub-mkimage; 第 二 阶段 
是 安装 boot.img 及 core.img 到 硬盘 ，GRUB 提 供 的 工具 是 grub-setup。 为 了 方 
便 ，GRUB 将 这 两 个 过 程 封装 到 脚本 grub-install 中 。 


在 创建 core.img 时 ，grub-mkimage 需 要 获取 需要 加 入 core.img 的 模块 ， 
GRUB 也 提供 了 相应 的 工具 grub-probe。grub-install 利 用 这 个 工具 根据 内 核 映 
像 所 在 的 介质 ， 目 动 探 测 所 需要 的 模块 ， 并 将 它们 传 给 grub-mkimage。 以 
笔者 机 器 为 例 ， 使 用 grub-probe 探 测 磁盘 分 区 方式 和 文件 系统 的 的 方法 如 
下 : 


root@baisheng:~# grub-probe --target=partmap -d /dev/sdal 
msdos 


root@baisheng:~# grub-probe --target=fs -d /dev/sdal 
ext2 


1. 创 建 映像 


grub-install 首 先 调 用 grub-mkimage 创 建 core.img， 我 们 结合 其 源 代 码 来 
讨论 core.img 的 创建 过 程 。 


grub-2.00/util/grub-mkimage.c: 


01 static void generate image (..., FILE *out, .,..; Char *mods[], ,..) 
说 

03 

04 path list = grub util resolve dependencies (dir, 

05 "moddep.lst", mods); 

06 

07 kernel path = grub util get path (dir, "kernel.img"); 

08 3 

09 kernel img = load image32 (kernel path, ...); 

10 4 

Ll for (p = path list; p; p = p->next) 

2 { 

13 en 

14 grub util load image (p->name, kernel img + offset); 
1s 

16 } 

二 过 js 

18 compress kernel (image target, kernel img, kernel size + 
19 total module size, &core img, &core size, comp); 

20 vi 

2 if (image target->flags & PLATFORM FLAGS DECOMPRESSORS) 
2 { 

2 Ps 

24 switch (comp) 

25 { 

26 Be 

27 case COMPRESSION LZMA: 

28 name = "lzma decompress.img"; 

29 break; 

30 和 

31 } 

3 这 到 

33 decompress_ img = grub util read image (decompress path); 
34 部 和 

35 memcpy (full img, decompress img, decompress size); 


37 memcpy (full img + decompress_ size, core img, core size); 


39 core img = full img; 
40 core size = full size; 
41 } 


43 switch (image target->id) 
44 { 

45 case IMAGE 1386 _ PC: 

46 case IMAGE 1386 PC PXE: 
47 { 


49 boot path = grub util get path (dir, "diskboot.img"); 


5 boot img = grub util read image (boot path); 


53 { 


54 struct grub pc bios boot blocklist *block; 

S55 block = (struct grub pc bios boot blocklist *) 

56 (boot img + GRUB DISK SECTOR SIZE - sizeof (*block)); 
号 学 block->len = grub host to target16 (num) ; 


59 } 


61 grub util write image (boot img, boot size, out, 


62 outname); 


66 } 


68 grub util write image (core img, 


core size, out, outname); 


根据 上 面 的 代码 可 见 ， 创 建 core.img 的 主要 过 程 如 下 : 


1) generate_image 读 取 kernel.img 到 内 存 ， 见 代码 第 7~9 行 。 


2) 除了 kernel.img 外 ， 还 要 将 一 些 模 块 合并 到 core.img 中 。 传 递 给 函数 


generate_image 的 参数 mods 是 一 个 数组 ， 
core.img 中 的 模块 。 但 是 这 些 模块 可 能 还 


其 中 记录 的 是 每 个 要 合并 到 
依赖 其 他 模块 ， 所 以 代码 第 4~5 行 


是 检查 这 些 模块 的 依赖 模块 ， 并 将 这 些 模块 记录 到 链表 path_list 中 。 然 后 ， 
第 11~16 行 的 代码 将 这 些 模块 全 部 加 载 到 kernel.img 的 后 面 。 


3) 至 此 ，kernel.img 和 各 个 模块 组 成 的 core.img 组 效 完 成 。 为 了 在 62 个 
届 区 中 容纳 下 core.img， 所 以 代码 第 18~19 行 压缩 core.img。 对 于 基于 IA32 染 
构 的 PC，GRUB 使 用 的 默认 压缩 方法 是 LZMA 。 


4) 既然 压缩 了 core.img， 那 么 束 得 有 人 来 负责 解压 缩 。 如 同 内 核 采 用 
的 方法 ，GRUB 也 在 压缩 的 core.img 前 面 附加 了 一 段 未 经 压缩 的 指令 ， 见 代 
码 第 21~37 行 。 如 果 core.img 使 用 的 是 LZMA 上 压缩 方法 ， 则 generate_image 读 
取 lzma_decompress.img， 将 其 附加 a 到 core.img 的 前 面 。 


5) 如 果 core.img 是 为 基于 IA32 的 PC 创建 的 ， 那 么 在 core.img 的 最 前 面 还 
要 附加 一 个 diskboot.img， 代 码 第 43~66 就 是 准备 diskboot.img。 因 为 
diskboot.img 人 负责 将 core.img 中 除 diskboot.img 的 部 分 读 入 内 存 ， 因 此 ， 
diskboot.img 需 要 知道 core.img 所 在 的 届 区 信息 。 因 为 这 里 已 经 确定 了 
core.img 占 用 的 大 小 ， 所 以 ，generate_image 将 core.img 占 用 的 情 区 数 写 入 了 
diskboot.img 最 后 的 blocklist 中 ， 这 就 是 代码 第 53~59 行 的 目的 。 准 备 好 
diskboot.img 后 ，generate_image 将 其 写 入 了 在 做 盘 上 保存 core.img 的 文件 ， 
见 代 码 第 61~62 行 ， 其 中 out 束 是 对 应 的 文件 core.img 。 


6) 在 将 diskbootimg 写 入 磁盘 文件 core.img 后 ，generate_image 将 内 存 中 
的 core.img 的 其 他 部 分 ， 包 括 lzma_decompress.img、kernel.img 以 及 需要 合并 
到 core.img 中 的 模块 ， 也 写 入 磁盘 上 的 文件 core.img 中 ， 紧 接 在 diskboot,img 
之 后 。 至 此 ，core.img 映 像 创 建 完毕 。 


2. 安 闭 有 映像 


创建 完 core.img 映 像 后 ，grub-install 将 调用 grub-setup 将 core.img (包括 
bootimg) 安装 到 硬盘 。 下 面 我 们 结合 grub-setup 的 代码 来 讨论 这 一 过 程 。 


grub-2.00/util/grub-setup.c: 


01 static void setup (...) 


0 A 

03 

04 boot img = grub util read image (boot path); 

05 ns 

06 core img = grub util read image (core path); 

07 ss 

08 LE (1 Tom 

09 err = grub util ldm embed (dest dev->disk, &nsec, maxsec, 
10 GRUB_ EMBED PCBIOS, &sectors); 
Ll else if (dest partmap) 

12 err = dest partmap->embed (dest dev->disk, &nsec, maxsec, 
be) GRUB_EMBED PCBIOS, &sectors); 
14 else 

15 err = fs->embed (dest dev, &nsec, maxsec, 

16 GRUB_ EMBED PCBIOS, &sectors); 

es > 这 

18 £6 人 3 13 dd BEGF 二 二 全) 

19 save blocklists (sectors[i] + grub partition get start 
20 (container), 0, GRUB DISK SECTOR SIZE); 

21 5 

22 write rootdev (core img, root dev, boct img, first Sector)7 
23 Fi 

24 £0r (4 = OF 1 Naes Ter) 

25 grub disk write (dest dev->disk, sectors[i], 0, 

26 GRUB DISK SECTOR SIZE, 

2 core img + i * GRUB DISK SECTOR SIZE); 
28 Pe 

29 if (grub disk write (dest dev->disk, BOOT SECTOR, 

30 0, GRUB DISK SECTOR SIZE, boot img)) 

区 省 

32 :] 


根据 上 述 代码 可 见 ， 安 装 GRUB 的 主要 过 程 如 下 : 
1) grub-setup 首 先 读 取 bootimg 和 core.img 到 内 存 ， 见 代码 第 4~6 行 。 


2) boot.img 的 安装 位 置 是 固定 的 ， 即 MBR， 但 是 grub-setup 需 要 确定 
core.img 安 装 的 局 区 。 对 于 不 同 的 情况 ， 确 定 的 方法 是 不 同 的 。 代 码 第 8~10 
行 是 针对 多 个 磁盘 组 成 的 逻辑 盘 的 情况 。 否 则 依次 尝试 使 用 具体 分 区 方案 


以 及 文件 系统 提供 的 embed 函 数 ， 见 代码 第 11~16 行 。 代 表 MBR 分 区 方案 的 
对 象 是 msdos， 其 中 提供 了 获取 安装 GRUB 所 在 的 硬 区 函数 


pc_partition_map_embed， 该 函数 将 计算 core.img 安 闭 的 忆 区 ， 并 将 结果 保存 
到 数组 sectors 中 。 变 量 nsec 记 有 录 的 是 core.img 占 用 局 区 数 。 


3) 在 确定 了 core.img 的 安装 局 区 后 


， 显 然 要 将 diskboot.img 中 的 blocklist 
填充 上 ， 代 码 第 18~20 行 就 是 在 做 这 件 事 。 


4) 一 旦 确定 了 core.img 安 装 的 扇 区 ，grub-setup 还 要 修订 bootimg。 虽 
然 对 奶 入 式 安装 而 言 ，diskboot.img 束 安 装 在 第 2 个 而 区 ， 但 是 GRUB 不 能 进 
行 这 样 的 假设 ， 因 为 还 有 可 能 使 用 非 芥 入 的 安装 方式 。 因 此 ，grub-setup 需 
要 设置 boot.img 中 diskbootimg 所 在 的 局 区 ， 见 代码 第 22 行 。 其 中 所 请 的 
first_sector 束 是 core.img 的 第 1 个 硝 区 ， 即 diskboot.img 占 据 的 硬盘 请 区 。 


5) 映像 准备 好 后 ， 如 果 采 用 和 骨 入 式 安 装 ， 那 么 需要 将 core.img 稚 入 


MBR 后 面 的 空 几 局 区 ， 即 数组 sectors 中 记录 的 而 区 ， 见 代码 第 24~27 行 。 对 
于 葡 入 式 安 疾 ， 因 为 是 艇 入 在 一 块 连续 的 悄 区 ， 所 以 diskboot.img 中 只 需要 
记录 一 个 blocklist， 如 图 5-3 所 示 。 


core.img 
F ¥ + 
bo ‘tic | e 
| 河 | 四 | core .img | Partition 1 ] 
:Un , 
. 学 
约 :所 
boot.img blocklist area 


~ 
diskboot.img 


core.img = diskboot.img + core'.img 


core'.img = lzma decompress.img + kernel.img + ext2.mod + other mods 


图 5-3 租 入 式 安装 GRUB 示 意图 


6) 最 后 ，grub-setup 将 boot.img 写 入 MBR， 见 代码 第 29~30 行 。 


为 简单 起 见 ， 上 面 代码 中 略 去 了 非 巷 入 式 安装 的 情况 。 在 非 嵌 入 式 安 
闭 情 况 下 ，GRUB 不 需要 将 保存 在 文件 系统 中 的 core.img 写 入 到 MBR 后 面 空 
朵 的 面 区 中 ， 而 只 需要 将 文件 系统 中 的 core.img 所 在 的 而 区 写 入 disboot,img 
的 blocklist， 将 diskboot.img 所 在 的 厨 区 写 入 boot.img 即 可 。 因 为 core.img 很 有 
可 能 不 是 连续 存储 在 硬盘 上 的 ， 所 以 diskboot.img 中 需要 记录 多 个 blocklist， 
这 就 是 diskboot.img 后 面 预 留 了 多 个 blocklist 空 间 的 原因 ， 如 图 5-4 所 示 。 


让 core'-1.img Core'-2.img | 
加 | | 1 
-一 一 一 一 一 
boot.img blocklist area 
一 


diskboot.img 


Partition 1 
core.img = diskboot.img + core'-1.img + core'-2.img 


core' -1.img + core'-2.img = lzma decompress.img + kernel.img + ext2.mod + other mods 


图 5-4 非典 入 式 安装 GRUB 示 意图 


5.1.3 GRUB 启 动 过 程 


我 们 知道 ， 在 PC 启动 时 ，BIOS 会 将 MBR 中 的 程序 加 载 到 内 存 的 0x7c00 
处 ， 并 跳 转 到 那里 开始 执行 。 对 于 GRUB 来 说 ， 对 应 MBR 中 的 映像 是 
boot.img， 在 编译 boot.img 时 ， 编 译 脚本 确实 也 是 指导 链接 器 从 0x7c00 开 始 
为 其 指令 和 数据 分 配 地址 的 ， 如 下 面 编译 脚本 片段 中 使 用 黑体 标识 的 部 
分 : 

grub-2.00/grub-core/Makefile. core.am: 


if COND i386 pc 
platform PROGRAMS += boot.image 


le ne LDN = $(AM LDFLAGS) $ (LDFLAGS IMAGE) ... 0x7c00 
GR 
读者 可 能 会 注意 到 脚本 中 映像 的 后 级 是 "image"， 而 不 是 "img"， 这 是 因 
为 编译 脚本 最 后 会 将 ELF 格 式 的 boot.image 转 换 为 裸 二 进 制 格 式 ， 并 命名 为 
boot.img。 其 余 映 像 也 是 如 此 处 理 。 


当 跳 转 到 0x7c00 后 ，GRUB 开 始 执 行 ， 其 启动 过 程 大 体 如 图 5-5 所 示 。 
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图 5-5 GRUB 启 动 过程 
(1) bootimg 加 载 diskboot.img 


bootimg 使 用 BIOS 中 断 号 为 0x13 的 基于 扇 区 的 磁盘 读 写 服务 加 载 
diskboot.img。GRUB 使 用 从 0x70000 开 始 处 的 一 段 内 存 作 为 BIOS 读 缓存 ， 所 
以 BIOS 首 先 将 diskboot.img 读 到 内 存 0x70000 处 ， 然 后 bootimg 再 将 其 移动 到 
内 存 0x8000 处 。 根 据 下 面 脚本 片段 中 黑色 标识 的 部 分 可 见 ， 链 接 器 确实 是 
从 0x8000 为 diskboot.img 分 配 地 址 的 : 


grub-2.00/grub-core/Makefile.core.am: 


if COND i386 pc 
platform PROGRAMS += diskboot.image 


diskboot image LDFLAGS = $(AM LDFLAGS) $ (LDFLAGS IMAGE) ... 0x8000 


diskboot image OBJCOPYFLAGS = $ (OBJCOPYFLAGS IMAGE) -OO binary 
endif 


boot.img 将 diskboot image 加 载 完 成 后 ， 跳 转 到 diskboot 中 的 第 一 条 指令 
处 继续 执行 。 


(2) diskboot.img 加 载 core.img 


与 boot.img 类 似 ，diskboot.img 使 用 BIOS 中 断 号 为 0x13 的 基于 刷 区 的 磁 
盘 读 写 服务 加 载 core.img。BIOS 将 lore.img 读 到 缓存 0x70000 处 ， 然 后 
diskboot.img 将 其 移动 到 0x8200 处 ， 最 后 跳 转 到 0x8200 处 开始 执行 


lzma_decompress.img ° 
(3) core.img 自 解压 


在 讨论 GRUB 创 建 映像 时 ， 我 们 看 到 ， 连 接 在 core.img 前 剖 的 
lzma_decompress.img 并 没有 倍 压 缩 ， 而 这 上 段 没 有 被 压缩 的 部 分 的 作用 束 古 
人 负责 解压 core.img 其 余 压 缩 的 部 分 。 我 们 来 看 看 构建 lzma_decompress.img 的 
脚本 片段 : 


grub-2.00/grub-core/Makefile .core .am: 


if COND i386 pc 
platform PROGRAMS += lzma decompress.image 


lzma decompress image SOURCES = boot/i386/pc/startup raw.s 
lzma decompress image LDFLAGS = $(AM LDFLAGS) ... 0x8200 
endif 


core.img 被 diskboot.img 加 载 到 0x8200 处 ，lzma_decompress.img 作 为 
core.img 的 开头 ， 其 地 址 应 该 从 0x8200 分 配 ， 根 据 上 面 的 编译 脚本 ， 即 可 见 
这 一 点 。 


从 脚本 可 见 ，lzma_decompress.img 的 开头 是 startup_raw.S， 其 正 是 解压 
core.img 的 地 方 ， 见 下 面 的 代码 : 


grub-2.00/grub-core/boot/i386/pc/startup raw.s: 


#ifdef ENABLE LZMA 
movl $SGRUB MEMORY MACHINE DECOMPRESSION ADDR, gedi 


pushl Sedi 


push Secx 


call _LzmaDecodeA 
pop %ecx 
/* LzmaDecodeA clears DF, so no need to run cld */ 
popl Sesi 
#endif 


jmp *%esi 


#ifdef ENABLE LZMA 
#include "lzma decode.S" 
#endif 


其 中 ，_LzmaDecodeA 束 是 进行 解压 的 画 数 ， 其 实现 在 文件 
lzma_decode.S 中 ， 所 以 startup_raw.S 将 这 个 文件 包含 进来 。 
lzma_decompress.img 将 core.img 解 压 到 内 存 
GRUB_MEMORY_MACHINE_DECOMPRESSION_ADDR 人 处 ， 定 义 如 下 : 


grub-2.00/include/grub/i386/pc/memory.h: 


/* The area where GRUB is decompressed at early startup. */ 
#define GRUB MEMORY MACHINE DECOMPRESSION ADDR 0x100000 


因为 低 端 内 存 捉襟见肘 ， 所 以 GRUB 使 用 从 1MB 开 始 的 空间 作为 解压 的 
缓冲 区 。 


GRUB 之 所 以 能 访问 1MB 以 上 的 内 存 地 址 ， 是 因为 开启 了 CPU 的 保护 模 
式 。 但 是 GRUB 并 没有 局 用 分 页 ， 而 是 采用 了 段 式 寻 址 ， 而 且 还 采用 了 特殊 
的 平坦 内 存 模 型 \flat model) ， 即 段 基 址 为 0。 平 坦 内 存 模型 的 寻 址 比较 简 
单 ， 某 种 意义 上 就 是 短路 了 CPU 的 段 机 制 ， 对 于 未 开局 分 页 的 平坦 内 存 模 
型 ， 偏 移 地 址 就 是 最 后 的 物理 地 址 。GRUB 中 使 用 了 平坦 内 存 模 型 的 GDT 的 
设置 如 下 : 


grub-2.00/grub-core/kern/i386/realmode.s: 


gadt: 
.word gwz 浊 
.byte Qs We Min OO 


/* -- code segment -- 
* base = Ox00000000, limit = OxFFFFF (4 KiB Granularity), present 
* type = 32bit code execute/read, DPL = 0 


.word OXFFFF, 0 
.byte Qs MORINy OACE NO 


* base = Ox00000000, limit OxFFFFF (4 KiB Granularity), present 
* type = 32 bit data read/write, DPL = 0 


.word OXxFFFF, 0 
.byte 0 OER REE; 0 


/* this is the GDT descriptor */ 
gdtdesc: 
.word 0x27 ns Tm 
.long gdt /* addr */ 


core.img 解 压 完成 后 ，lzma_decompress.img 将 跳 转 到 解压 的 core.img 处 
继续 执行 。 根 据 前 面 讨论 的 core.img 的 构成 ，core.img 的 压缩 部 分 包括 
kermelimg 和 必要 的 模块 ， 所 以 经 过 这 次 跳 转 后 ，GRUB 跳 转 到 了 映像 
kernel.img 的 开头 。 


(4) kernel.img 将 自己 复制 回 0x9000 


为 Linux 内 核 和 initramfs 可 能 被 加 载 到 内 存 从 1MB 开 始 的 任何 地 方 ， 
所 以 GRUB 要 给 它们 指 路 。 为 此 ，GRUB 虽 然 使 用 了 1MB 以 上 的 区 域 作 为 解 
压 使 用 的 缓冲 区 ， 但 是 解压 后 要 移动 回 I1MB 以 下 的 区 域 。 


我 们 看 一 下 kernel.img 的 构建 脚本 : 


grub-2.00/grub-core/Makefile .core.am: 


if: COND 1386 BG 

platform PROGRAMS += kernel .exec 

kernel exec SOURCES = kern/i386/pc/startup.s 
kernel exec SOURCES += kern/generic/rtc get time ms.c 
term/i386/vga common.c kern/i386/pc/init.c ... 


kernel exec LDFLAGS = $(AM LDFLAGS) $ (LDFLAGS KERNEL) ...,0x9000 


kernel .img: kernel .execs$ (EXEEXT) 
...$(STRIP) S$ (kernel exec STRIPFLAGS) -oOo $@ $< ... 
endif 


根据 kernelimg 的 编译 脚本 可 见 ，kernelimg 的 开头 是 startup.S， 移 动 
kernelimg 的 代码 瓯 在 这 个 文件 中 : 


grub-2.00/grub-core/kern/i386/pc/startup.s: 


start: 
本 


#ifdef APPLE _ 


movl $EXT C( edata), $%ecx 

subl $SLOCAL (start), %Secx 
#else 

movl $( edata - start), $%ecx 
#endif 

movl $(_start), %edi 

rep 

movsb 

movl SLOCRAT (cont), %esi 

jmp *%esi 
LOCAL (cont ) : 


| EXT Cl(lgrub main) 
根据 startup.S 的 代码 可 见 : 
1) startup.S 调 用 x86 的 指令 movsb 移 动 映 像 。 


2) 寄存 器 esi 中 的 值 是 移动 的 源 地 址 。 在 解压 core.img 时 ， 解 压 后 的 
core.img 的 地 址 ， 即 1MB， 已 经 保存 在 寄存 器 esi 中 了 。 


3) 寄存 器 edi 的 值 是 移动 的 目的 地 址 。 在 代码 中 ， 寄 存 器 edi 的 值 被 设 
置 为 符号 _start 的 地 址 ， 这 个 符号 地 址 是 多 少 昵 ?注意 编译 脚本 中 传 给 链接 
句 的 参数 kernel_exec_LDFLAGS， 其 请 求 链 接 器 从 0x9000 开 始 为 kernel.img 
分 配 地 址 ， 而 _start 恰 位 于 kernelimg 的 开头 ， 所 以 符号 _start 的 地 址 是 
0x9000。 因 此 ，kernel.img 束 是 将 目 身 移动 到 0x9000 处 。 


4) 寄存 器 ecx 的 值 是 移动 的 字 节 数 。 从 代码 中 计算 ecx 的 值 来 看 ， 
startup.S 只 移动 从 _edata 到 _start 的 这 段 指 令 和 数据 ， 而 _edata 是 链接 絮 定 义 
的 代表 kernel.img 的 数据 段 结束 的 位 置 ， 也 就 是 说 ，startup.S 只 是 将 
kernel.img 移 动 到 了 0x9000 处 ， 并 没有 移动 模块 。 在 讨论 core.img 的 构成 时 ， 
我 们 已 经 谈 到 模块 需要 重 定位 ， 所 以 不 能 简单 地 进行 移动 。 


5) 在 移动 完 kermel.img 后 ，startup.S 再 次 使 用 跳 转 指 令 jmp 跳 转 到 了 移 
动 后 的 位 置 继续 执行 ， 并 转 入 了 GRUB 真 正 的 核心 部 分 ， 即 C 话 言 写 的 函数 
grub_main 处 。 


grub-2.00/grub-core/kern/main.c: 


void attribute _{((noreturn)) grub main (void) 


{ 
grub load modules (); 


grub load normal mode (); 


函数 grub_main 调 用 函数 grub_load_modules 凌 配 模 块 ， 然 后 调用 
grub_load_normal_mode 加 载 normal 模 块 ， 这 个 模块 拉 开 了 加 载 Linux 内 核 和 
initramfs 的 大 幕 。 


5.1.4 加 载 内 核 和 initramfs 


normal 模 块 读 取 并 解析 GRUB 配 置 文件 grub.cfg， 然 后 根据 grub.cfg 中 的 
具体 命令 ， 加 载 相 应 的 模块 。 命 令 和 模块 的 关系 记录 在 文件 command.lst 
中 ， 通 常 GRUB 将 该 文件 被 安装 在 /boot/grub/i386-pc 目 录 下 ，normal 模 块 加 
载 时 将 加 载 这 个 文件 。command.lst 包 括 两 列 ， 第 一 列 是 命令 ， 第 二 列 是 该 
命令 所 在 的 模块 : 


/boot/grub/i386-pc/command.1st: 


NLLALTG: LEnUxL6 
nLiteds no 

Keymap : keylayouts 
kfreebsd loadenv: bsd 
kfreebsd module: bsd 
kfreebsd module elf: bsd 


J nuxlGs TINnuxlis6 
Lin 11nux 


以 下 面 的 GRUB 配 置 文件 中 的 片段 为 例 : 


set root=(hd0,1) 
linux /boot/bzImage root=/dev/sdal ro quiet splash 
inityd /boOot/initrdsing 


当 normal 模 块 遇 到 命令 如 "linux"、"initrd" 时 ， 将 到 文件 command.lst 中 查 
找 这 些 命令 所 在 的 模块 。 根 据 command.lst 可 知 ， 命 令 "inux"、"initrd" 都 在 
模块 linux 中 ， 因 此 ，normal 模 块 将 加 载 linux 模 块 。 然 后 ， 调 用 linux 模 块 中 
的 命令 "linux"、"initrd"， 完 成 Linux 内 核 以 及 initramfs 的 加 载 。 本 和 中 ， 我 们 
通过 分 析 这 两 个 命令 对 应 的 回调 函数 ， 来 探讨 Linux 内 核 和 initramfs 的 加 
载 。 


1. 引 导 协 议 


Bootloader 负 责 加 载 内 核 ， 显 然 Bootloader 和 内 核 之 间 需 要 分 享 一 些 数 
据 。 典 型 的 比如 Bootloader 需 要 知道 内 核 的 保护 模式 部 分 希望 加 载 到 什么 位 
置 ? 内 核 是 不 是 可 重 定位 内 核 ? 从 内 核 的 角度 ， 则 需要 清楚 Bootloader 将 
initramfs 加 载 到 了 内 存 的 什么 位 置 、initramfs 的 尺寸 是 多 少 等 。 


因此 ， 内 核 和 引导 程序 之 间 需 要 有 个 约定 ， 这 个 约定 称 为 引导 协议 
(boot protocol) ， 也 称 为 16 位 引导 协议 (16-bit boot protocol) 。 该 协议 约 
定 了 Bootloader 和 内 核 之 间 分 享 的 数据 存储 的 位 置 、 大 小 以 及 哪些 由 内 核 提 


供给 Bootloader， 哪 些 由 Bootloader 提 供给 内 核 等 。 


在 进入 保护 模式 后 ， 内 核 将 不 会 再 切换 到 实 模式 ， 而 硬件 相关 的 参数 
必须 在 实 模式 下 借助 BIOS 中 断 获 了 到 。 为 此 ， 在 早期 的 内 核 中 ， 内 核 中 包含 
了 一 部 分 实 模式 代码 ， 即 setup.bin， 其 主要 功能 之 一 束 是 为 保护 模式 部 分 的 
代码 获取 硬件 的 信息 ， 也 就 是 内 核 中 所 说 的 零 页 (zero-page) 中 规定 的 信 


自 。 


Ts 


随 着 新 的 BIOS 标 准 ， 如 EFI、LinuxBIOS 等 的 出 现 ， 出 现 了 32 位 引导 协 
议 (32-bit boot protocol) 。 在 32 位 引导 协议 下 ， 除 了 传统 的 16 位 协议 ， 
Bootloader 取 代 内 核 中 实 模式 部 分 负责 收集 硬件 信息 ( 即 零 页 信息 ) 的 功 
能 。 而 且 Bootloader 会 将 CPU 切换 为 保护 模式 ， 在 内 核 和 initramfs 加 载 完成 
后 ，Bootloader 不 再 跳 转 到 内 核实 模式 部 分 ， 而 是 直接 跳 转 到 内 核 的 保护 模 


下 面 我 们 束 来 看 看 在 32 位 引导 协议 下 ， 内 核 和 Bootloader 之 间 是 如 何 分 


享 信息 的 。 
(1) 内 核 向 Bootloader 传 递 信 息 
内 核 中 引导 协议 的 相关 部 分 在 文件 arch/x86/booyheader.S 中 : 


linux-3.7.4/arch/x86/boot/header.s: 


.Section ".header", "a" 
ene .long 0 
ramdisk size: .long 0 
el .long CONFIG PHYSICAL ALIGN 
relocatable kernel: byte 1 
ee .quad LOAD PHYSICAL ADDR 


上 面 列 出 了 几 个 典型 的 信息 ， 其 中 ramdisk_image 和 ramdisk_size 是 由 
Bootloader 人 负责 填充 的 ， 告 诉 内 核 initramfs 被 加 载 到 了 内 存 的 什么 位 置 ， 占 


据 多 大 空间 。 而 kernel_alignment、relocatable_kernel、Ppref_address 则 由 内 核 
负责 填充 ， 告 知 Bootloader 内 核 加 载 的 对 齐 要求 、 内 核 是 否 是 可 以 重 定位 的 
以 及 内 核 希 望 的 加 载 地 址 等 信息 。 


引 守 协议 规定 ， 协 议 数据 从 内 核 映像 的 偏 移 0x1F1 处 开始 ， 所 以 在 
header.S 中 使 用 汇编 伪 指 令 .section".header" 指 示 编 译 器 将 引导 数据 所 在 的 段 
定义 为 ".header"， 并 在 setup.bin 的 链接 脚本 中 将 此 段 安排 在 内 核 映 像 偏 移 
0x1F1 处 : 


linux-3.7.4/arch/x86/boot/setup.1d: 


SECTIONS 


{ 


;9 
.header : { *(.header) } 


} 


setup.1d 指 示 链 接 需 将 段 ".header" 链 接 在 地 址 497 处 ， 其 十 六 进 制 即 
0x1F1， 这 恰 是 引导 协议 约定 的 位 置 。GRUB 加 载 内 核 时 ， 将 首先 从 
setup.bin 中 读 取 3 引导 协议 相关 的 信息 。 


对 于 零 页 中 规定 的 信息 ， 并 不 需要 从 内 核 传递 给 Bootloader， 所 以 
setup.bin 中 定义 的 依然 是 传统 的 16 位 引导 数据 。 


(2) Bootloader 向 内 核 传递 信息 


Bootloader 癌 内 核 传 递 的 信息 ， 要 比 内 核 向 Bootloader 的 传递 复 灯 一 
些 。 因 为 除了 传统 的 16 位 引导 信息 外 ， 还 需要 向 内 核 传递 零 页 信息 。 
Bootloader 和 内 核 均 为 此 定义 了 一 个 数据 结构 ， 通 党 将 这 个 结构 体 称 为 引导 
参数 (boot parameters) 。GRUB 中 的 定义 如 下 : 


grub-2.00/include/grub/i386/linux.h: 

struct linux kernel params 

{ 
grub uint8 t video cursor x; /* 0 */ 
grub uint8 t video cursor y; 


grub uint8 t padding9 [0x1f1 - 0xle9]; 


grub uint8 t setup sects; /* The size of the setup in sectors */ 
grub uint16 t root flags; /* If the root is mounted readonly */ 


struct grub e820 mmap e820 map[(0x400 - 0x2d0) / 20]; /* 2d0 */ 


} _attribute _ ((packed)); 


在 结构 体 linux_kernel_params 中 ， 从 偏 移 0x1F1 处 ， 即 成 员 setup_sects 
处 ， 保 存 的 传统 的 16 位 引导 协议 的 数据 。 除 此 之 外 ， 结 构 体 
linux_kernel_params 中 保存 就 是 零 页 信息 了 ， 如 显示 相关 的 信息 、 内 存 相 关 
的 信息 等 。 


GRUB 在 启动 内 核 前 ， 将 创建 一 个 结构 体 linux_kernel_params 类 型 的 变 
量 linux_params， 首 先 从 setup.bin 中 该 取 16 位 的 引导 数据 到 这 个 变量 中 ， 代 
码 如 下 : 


grub-2.00/grub-core/loader/i386/linux.c: 
static struct linux kernel params linux params; 


static grub err t grub cmd linux (grub command t cmd _attribute _ 
((unused)), int argc, char *argv[]) 
{ 


grub file t fle = 0; 


struct linux kernel header lh; 
struct linux kernel params *params; 


file = grub file open (argv[0]); 
if (grub file read (file, &lh, sizeof (lh)) != sizeof (lh)) 
params = (struct linux kernel params *) &linux params; 


grub memset (params, 0, sizeof (*params)); 
grub memcpy (&params->setup sects, &lh.setup sects, 


SL2eoE (Li) = MELEL): 
params->ext mem = ((32 * 0x100000) >> 10); 
params->alt mem = ((32 * 0x100000) >> 10); 


grub_cmd_linux 是 模块 linux 中 的 命令 linux 的 回调 函数 ， 跟 在 命令 linux 后 


的 第 一 个 参数 就 古 内 核 映 像 文件 ， 因 此 ， 这 里 的 argv[0] 就 古 内 核 映 像 文 


件 。 画 


数 grub_cmd_linux 从 内 核 映 像 的 开头 读 取 了 结构 体 linux_kernel_header 


大 小 的 一 块 数据 ， 结 构 体 linux_kernel_header 定 义 的 就 是 传统 的 16 位 的 引导 


数据 : 


grub-2.00/include/grub/i386/linux.h: 


/* For the Linux/i386 boot protocol version 2.10. */ 
struct linux kernel header 


{ 


grub uinte tt Code2[0x0lEL ™ 0x0020 2 2 hy 
grub uint8 t setup sects; /* The size of the setup in sectors */ 


grub uint64 t pref address; 
gub int € Jnit slses 
} _attribute _  ((packed)); 


然后 ，grub_cmd_linux 将 其 复制 到 变量 linux_params 中 。 


GRUB 除 了 使 用 从 内 核 中 读 取 的 信息 ， 比 如 内 核 希 望 加 载 的 地 址 ， 也 将 
实际 加 载 的 情况 《比如 initramfs 加 载 的 位 置 ) 填充 到 变量 linux_params 中 。 
另外 ，GRUB 还 要 按照 32 位 局 动 协议 规定 ， 检 测 零 页 定义 的 信息 ， 填 充 到 变 
量 linux_params 中 。 比 如 在 上 面 列 出 的 函数 grub_cmd_linux 的 代码 片段 中 设 
置 linux_kernel_params 中 的 ext_mem 和 alt_ mem 等 。 再 举 一 个 典型 的 例子 ,在 
引导 Linux 内 核 前 ，GRUB 会 将 探测 到 的 内 存 的 信息 记录 在 变量 linux_params 
中 : 


grub-2.00/grub-core/loader/i386/linux.c: 


static grub err t grub linux boot (void) 


{ 


if (grub e820 add region (params->e820 map, &e820 num, 
addr, size, e820 type)) 


在 内 核 中 ，3 引 导 信 息 定义 的 数据 结构 如 下 : 


linux-3.7.4/arch/x86/include/asm/bootparam.h: 
struct setup header { 

_u8 setup_ sects; 

UL6 root flags; 


} _ attribute _((packed) ) ; 


struct boot params { 
struct screen info screen info; /* Ox000 */ 


struct setup header hdr; /* setup header */ /* Oxlf1 */ 


struct e820entry e820 map [E820MAX]; /* Ox2d0 */ 


其 中 ， 结 构 体 setup_header 中 记录 的 就 是 传统 的 16 位 引导 信息 ， 结 构 体 
boot_params 对 应 于 GRUB 中 的 结构 体 linux_kernel_params， 即 记录 的 是 传统 
的 16 位 的 引导 信息 和 零 页 信息 。 在 初始 化 时 ， 内 核 会 将 GRUB 准 备 好 的 这 些 
言 息 复制 到 内 核 的 地 址 空间 中 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/kernel/head 32.S: 
ENTRY (startup 32) 


movl1 s$pal(lboot params),%edi 

movl $ (PARAM SIZE/4),%ecx 

EL 

rep 

movsl 

movl palboot params) + NEW CL POINTER,%esi 
andl S$%Sesi,S%esi 

于 下 # No command line 
movl1 S$pal(lboot command 1ine) ,sedi 
movl $ (COMMAND LINE SIZE/4),$%ecx 
rep 

movsl 


内 核 重 复 调 用 汇编 指令 movsl 进 行 复制 。 复 制 的 源 寄存 器 esi 在 GRUB 中 
局 动 内 核 前 设置 指 疝 linux_kernel_params 对 象 ， 目 的 地 址 是 内 核 中 定义 的 结 


构 体 boot_params 类 型 的 变量 boot_params 。 


如 采用 户 通 过 GRUB 问 内核 传递 了 参数 ， 即 我 们 所 说 的 grub.cfg 中 的 命 
令 行 参数 ， 则 GRUB 将 这 些 参数 保存 在 一 块 内 存 中 ， 并 设置 引导 参数 结构 体 
中 的 字段 cmd_line_ptr 指 癌 这 块 内 存 ， 内 核 也 要 将 这 些 参数 从 GRUB 复 制 到 
内 核 。 


2. 加 载 内 核 及 initramfs 


理解 了 引导 协议 后 ， 接 下 来 看 看 GRUB 是 如 何 加 载 内 核 以 及 initramfs 到 
内 存 的 。 


模块 jinux 初 始 化 时 注册 了 两 个 命令 ， 一 个 是 命令 linux， 另 外 一 个 是 
initrd。 命 令 linux 的 作用 是 加 载 Linux 内 核 ， 其 对 应 的 回调 函数 是 
grub_cmd_linux; 命令 initrd 的 作用 是 加 载 initramfs， 其 对 应 的 回调 函数 是 
grub_cmd_initrd， 代 码 如 下 : 


grub-2.00/grub-core/loader/i386/linux.c: 


GRUB MOD INIT (linux) 
人 
cmd linux = grub register command ("linux", grub cmd linux, 
0 WN (vad Lm. }):; 
cmd initrd = grub register command ("initrd", grub cmd initrd, 
Ox WN (Load 到 LE 
my_mod = mod; 


} 


(1) 加 载 内 核 


前 面 提 到 过 ， 在 32 位 引导 协议 下 ， 内 核 的 实 模 式 部 分 已 经 退化 为 仅 负 
责 承 载 引 导 协 议 ， 其 功能 部 分 已 经 被 GRUB 取 代 了 ， 所 以 实 模式 部 分 无 须 再 
加 载 到 内 存 了 。GRUB 只 需 将 内 核 的 保护 模式 加 载 到 内 存 即 可 ， 相 关 代 码 如 
下 : 


grub-2.00/grub-core/loader/i386/linux.c: 


01 static void *prot mode mem; 
02 static grub addr t prot mode target; 


03 

Q4 atatie grub Grr t Grub. nd Linus (ve 

05 { 

06 和 

07 grub_uint64 t preffered address = GRUB LINUX BZIMAGE ADDR; 
08 人 

09 setup sects = lh.setup sects; 

10 Sg 

1 real size = setup_ sects << GRUB DISK SECTOR BITS; 

22 prot file size = grub file size (file) - real size -一 

13 GRUB DISK SECTOR SIZE; 

14 人 

15 if (grub le to cpulé6 (lh.version) >= 0x020a) 

16 { 

于 人 

18 if (relocatable) 

Ts preffered address = grub le _to_cpu64 (lh.pref address); 
20 else 

2 preffered address = GRUB LINUX BZIMAGE ADDR; 

22 } 

23 i 

24 if (allocate pages (prot size, &align, min align, 

2 relocatable, preffered address)) 

26 

27 params->code32 start = prot mode target + lh.code32 start 
28 - GRUB LINUX BZIMAGE ADDR; 

29 


30 grub file seek (file, real size + GRUB DISK SECTOR SIZE); 


31 i 

32 len = prot file size; 

33 if (grub tile read. (下 Le prot. mode mem; len) != len && 3%% 1) 
34 

35 } 


在 讨论 函数 grub_cmd_linux 前 ， 首 先 解释 代码 中 出 现 的 两 个 容易 混淆 的 
prot_mode_mem 和 prot_mode_target， 见 代码 第 1 行 和 第 2 行 。 这 两 
个 变量 很 容易 让 人 困惑 ， 但 是 仔细 观察 它们 的 变量 类 型 可 以 发 现 ， 
prot_mode_mem 是 指向 一 块 内 存 的 指针 ， 所 以 读 写 内 存 操作 应 该 使 用 这 个 指 
针 。 而 prot_mode_target 记 录 的 仅仅 是 一 个 内 存 地 址 ， 典 型 的 用 作 跳 转 指令 
的 操作 数 。 比 如 跳 转 到 内 核 的 保护 模式 部 分 时 ， 指 令 jmp 后 接 的 操作 数 是 内 
存 地 址 ， 而 不 应 使 用 指向 内 存 的 指针 。 


==: 机 
变量 


函数 grub_cmd_linux 执 行 的 主要 操作 如 下 : 


1) 既然 准备 将 内 核 映 像 加 载 到 内 存 ， 函 数 grub_cmd_linux 首 先 确定 内 
核 希 望 加 载 的 地 址 ， 见 代码 第 15~22 行 。 以 大 于 0x020a 版 本 的 引导 协议 为 
例 ， 如 果 内 核 支 持 重 定位 ， 那 么 GRUB 将 从 引导 协议 中 读 取 的 pref_address 
作为 内 核 加 载 的 位 置 。 否 则 ， 将 内 核 加 载 到 位 置 
GRUB_LINUX_BZIMAGE_ADDR， 该 宏 在 GRUB 中 定义 为 1MB: 


grub-2.00/include/grub/i386/l1inux.h: 


#define GRUB LINUX BZIMAGE ADDR Ox100000 


2) 确定 了 加 载 地 址 后 ，grub_cmd_linux 调 用 函数 allocate_pages 为 内 核 
映像 分 配 内 存 ， 见 代码 第 24~25 行 。 同 时 ， 函 数 allocate_pages 设 置 指针 
prot_ mode_mem 指 回 为 内 核 分 配 的 内 存 ， 而 将 该 内 存 的 地 址 记录 在 变量 


prot_mode_target 中 9 


3) 函数 grub_cmd_linux 也 将 内 核 加 载 的 物理 地 址 ， 即 变量 
prot_mode_target 的 值 ， 记 录 在 引导 参数 的 成 员 code32_start 中 ， 见 代码 第 
27~28 行 。 后 面 局 动 内 核 时 的 跳 转 命令 将 以 code32_start 记 录 的 物理 地 址 作为 
操作 数 。 这 里 ，GRUB 的 开发 者 们 应 该 是 考虑 了 某 些 特殊 情况 ， 因 为 针对 我 
们 的 具体 情况 ，setup.bin 中 的 code32_start 定 义 为 1MB: 


linux-3.7.4/arch/x86/boot/header.s: 


code32 start: # here loaders can put a different 
# start address for 32-bit code. 
.long 0x100000 # 0x100000 = default for big kernel 


而 宏 GRUB_LINUX_BZIMAGE_ADDR 也 是 1MB， 所 以 lh.code32_start 
和 GRUB_LINUX_BZIMAGE_ADDR 是 相互 抵消 的 ， 变 量 code32_start 的 值 


就 是 prot_mode_target 。 


4) 准备 好 了 内 核 映 像 加 载 的 内 存 后 ， 下 面 就 要 准备 从 硬盘 将 内 核 映 像 
读 入 内 存 。 因 为 实 模式 部 分 不 需要 加 载 ， 所 以 读 取 前 需要 将 映像 文件 的 指 
针 定位 到 保护 模式 。 显 然 只 有 内 核 知 道 自己 的 实 模 式 部 分 有 和 多大， 因此， 
GRUB 需 要 从 承载 引导 协议 的 setup.bin 中 读 取 实 模式 部 分 的 尺寸 。 


最 初 ， 内 核 为 了 支持 从 软盘 启动 ， 实 模式 部 分 分 为 bootsect 以 及 setup 两 
部 分 。 后 来 引导 统一 由 Bootloader 来 负责 ， 因 此 ， 内 核 从 2.6 版 本 开始 把 
bootsect.S 文 件 和 setup.S 文 件 合成 为 一 个 文件 一 一 header.S 文 件 。 但 是 为 了 向 
后 兼容 ， 引 导 协 议 中 记录 setup 部 分 大 小 的 成 员 setup_sectors 依 旧 被 内 核 设置 
为 实 模 式 部 分 的 尺寸 再 减 去 一 个 局 区 ， 代 码 如 下 所 示 : 


linux-3.7.4/arch/x86/boot/tools/build.c: 


buf [0x1f1] = setup sectors-1,; 


代码 中 第 9 行 束 是 读 取 setup 部 分 占据 的 情 区 数 ， 第 11 行 是 将 局 区 转换 为 


EE 


5) 获取 了 实 模式 部 分 的 大 小 后 ， 下 面 就 要 将 内 核 映 像 文 件 定位 到 保护 
模式 开始 的 地 方 ， 第 30 行 代码 就 是 做 这 件 事 。 其 中 
GRUB_DISK_SECTOR_SIZE 就 是 在 setup 的 基础 上 再 增加 一 个 而 区 的 


bootsect 。 


6) 在 最 后 读 取 之 前 ， 还 有 一 件 事 要 做 ， 那 就 是 确定 保护 模式 部 分 的 尺 
寸 。 一 旦 确定 了 实 模 式 部 分 的 大 小 ， 保 护 模式 的 尺寸 整 非常 容易 计算 了 ， 
即 整个 映像 的 尺寸 减 去 实 模式 的 尺寸 (包括 setup 部 分 和 bootsect 部 分 ， 就 
征 保护 模式 的 大 小 ， 见 代码 第 12~13 行 。 


7) 一 切 就 绪 ， 第 33 行 代码 加 载 内 核 。 此 时 ，GRUB 已 经 加 载 了 驱动 人 硬 
盘 和 文件 系统 的 模块 ， 所 以 ，GRUB 不 再 是 通过 BIOS 中 断 ， 而 是 通过 自身 
的 文件 系统 驱动 提供 的 接口 grub_file_read 读 取 的 内 核 映像 。 


(2) 加 载 initramfs 


与 加 载 内 核 类 似 ， 命 令 initrd 对 应 的 回调 函数 grub_cmd_initrd 首 先 确定 
initramfs 的 加 载 地 址 ， 为 initramfs 分 配 好 内 存 。 然 后 调用 GRUB 中 的 文件 系 
统 张 动 提 供 的 接口 grub_file_read 从 硬盘 加 载 initramfs。 相 关 代码 如 下 : 


grub-2.00/grub-core/loader/i386/linux.c: 


DI atatls I er tt grub Sud Tmlery tw 


D2 4 

03 Fu 

04 if (grub le to cpul6 (linux params.version) >= 0x0203) 

05 { 

06 addr max=grub cpu to le32(linux params.initrd addr max) ; 
D7 

08 } 

09 else 

10 addr max = GRUB LINUX INITRD MAX ADDRESS; 

1 Ee 

12 addr min = (grub addr t) prot mode target + prot init space 
13 + page align (size); 

14 

15 /* Put the initrd as high as possible, 4KiB aligned. */ 

16 addr = (addr max - size) & ~OxFFF; 

4 二 

18 err = grub relocator alloc chunk align (relocator, &ch, 
19 addr min, addr, size, 0x1000, 


20 GRUB RELOCATOR PREFERENCE HIGH, 1); 


2 有 

22 initrd mem = get virtual current address (ch) ; 

23 initrd mem target = get physical target address (ch); 
24 i 

25 ptr = initrd mem; 

26 for (i = 0; i < nfiles; i++) 

2 { 

28 Ws 

29 if (grub file read (files[i], ptr, cursize) != cursize) 
30 

31 } 

32 rp 

33 linux params.ramdisk image = initrd mem target; 

34 linux params.ramdisk size = size; 

35 

36 } 


函数 grub_cmd_initrd 执 行 的 主要 操作 如 下 : 


1) grub_cmd_initrd 首 先 要 确定 initramfs 加 载 的 位 置 ， 见 代码 第 4~13 行 。 
从 引导 协议 0x0203 版 本 开始 ， 内 核定 义 了 加 载 initramfs 的 上 限 ， 以 Linux 内 
核 3.7.4 版 本 为 例 ， 其 规定 的 initramfs 的 上 限 为 Ox7fffffff: 


linux-3.7.4/arch/x86/boot/header.s: 


ramdisk max: Lng 7 上 上 下 二 于 下 下 二 


如 果 引 导 协 议 小 于 这 个 版 本 ， 则 GRUB 只 需 自己 作 主 即 可 ，GRUB 将 
initramfs 加 载 的 上 限 设置 为 GRUB_LINUX_INITRD MAX_ADDRESS: 


grub-2.00/includqe/grub/i386/1Linux.h: 


#define GRUB LINUX INITRD MAX ADDRESS OX37FFFFFF 


而 对 于 下 限 ， 内 核 没 有 要 求 。 但 是 根据 代码 可 见 ，GRUB 将 initramfs 加 
载 在 内 核 映 像 之 后 。 


2) 琐 数 grub_cmd_initrd 调 用 函数 grub_relocator_alloc_chunk_align 在 这 
个 范围 内 找 一 个 合适 的 位 置 ， 见 代码 第 18~20 行 。 根 据 传 给 函数 
grub_relocator_ alloc_chunk align 的 参数 
GRUB_RELOCAIOR_PREFERENCE_HIGH 可 见 ，GRUB 采 用 的 策略 是 尽 可 
能 的 将 initramfs 加 载 到 高 地 址 处 。 


为 initramfs 分 配 完 内 存 之 后 ，grub_cmd_initrd 将 指针 initrd_mem 指 辐 为 
加 载 initramfs 分 配 的 内 存 ， 并 将 这 块 内 存 的 物理 地 址 记录 到 变量 
initrd_mem_target 中 ， 见 代码 第 22~23 行 。 这 两 个 变量 与 前 面 讨 论 加 载 内 核 
时 见 到 的 变量 prot_mode_mem 和 prot_mode_target 类 似 。 最 后 这 个 内 存 地 址 
是 要 分 享 给 内 核 的 ， 当 然 不 能 将 GRUB 中 的 一 个 内 存 指针 传递 给 内 核 了 。 


3) 确定 了 地 址 ， 并 分 配 了 内 存 后 ， 琴 数 grub_cmd_initrd 调 用 
grub_file_read 将 initramfs 加 载 到 内 存 initrd_mem 处 。 这 里 GRUB 考 虑 了 可 能 
存在 多 个 initrd 的 情况 ， 所 以 有 个 for 循 环 。 


4) 最 后 ，GRUB 将 initramfs 的 尺寸 、 加 载 的 位 置 记录 到 引导 参数 中 ， 
供 内 核 寻 找 initramfs 时 使 用 ， 见 代码 第 33~34 行 。 这 里 ， 我 们 看 到 ， 传 递 给 
内 核 的 initramfs 的 加 载 地 址 加 是 前 面 分 配 的 内 存 的 物理 地 址 


initrd_mem target。 
3. 将 控制 权 交 给 内 核 


在 加 载 完 内 核 映 像 和 iniramfs 后 ，GRUB 完 成 了 其 作为 操作 系统 加 载 器 
的 使 命 ， 其 将 跳 转 到 加 载 的 内 核 映 像 ， 将 控制 权 交 给 内 核 。 相 关 代 码 如 


grub-2.00/grub-core/loader/i386/linux.c: 


01 static grub err 七 grub linux boot (volid) 
02 { 


04 params = real mode mem; 
06 *params = linux params; 


08 state.esi real mode target; 
09 state.esp real mode target; 
10 state.eip params->code32 start; 


3 return grub relocator32 boot (relocator, state, 0); 


基本 上 ，GRUB 是 运行 在 保护 模式 的 ， 只 有 在 使 用 BIOS 时 才 切 换 到 实 
模式 ， 所 以 记录 引导 参数 的 全 局 变量 linux_params 的 位 置 是 随机 的 。 因 此 ， 
在 局 动 内 核 前 ，GRUB 在 传统 的 低 端 内 存 中 申请 了 一 块 区 域 ， 将 引导 参数 放 
置 到 传统 的 实 模式 占据 的 位 置 。 画 数 grub_linux_boot 中 指向 这 块 内 存 的 指针 
是 real_mode_mem， 并 将 这 块 内 存 的 物理 地 址 记录 在 变量 real_mode_target 。 
最 终 ， 在 跳 转 到 内 核 之 前 ，GRUB 会 将 real_mode_target 记 录 到 寄存 器 esi 中 ， 
内 核 启 动 后 ， 将 从 寄存 器 esi 记 录 的 这 个 地 址 复制 引导 参数 。 


第 6 行 代码 就 是 将 变量 linux_params 的 值 复制 到 这 块 内 存 区 域 。 


第 10 行 设置 了 指令 指针 的 地 址 为 code32_start， 我 们 在 讨论 加 载 内 核 映 
像 时 已 经 见 到 了 code32_start， 其 就 是 内 核 保护 模式 加 载 的 地 址 。 最 后 ， 画 
数 grub_relocator32_boot 将 调用 函数 grub_relocator32_start 跳 转 到 内 核 的 保护 
模式 处 ， 代 码 如 下 : 


grub-2.00/grub-core/1lib/i386/relocator32 .3 : 


01 #define CODE SEGMENT 0X10 

02 we 

03 VARIABLE (grub relocator32 start) 

04 he 

05 RELOAD GDT 

06 

07 .byte 0Xea 

08 VARIABLE (grub relocator32 eip) 

09 .long 0 

10 .word CODE SEGMENT 

和 二 i 

12 LOCAL (gdt): 

| HR NULL: ， 涉 了 

14 we Ox00 OD 0 x00 0X00 0x00s OKO00 0200 
15 

16 /* Reserved. */ 

1 “byte 0x00, 0x00 OQx00; 0907 (0x00; 0x00, 0x00; OQx00 
18 

19 /* Code segment. */ 

20 byte OxEE: OxXEEF;: 0x00r 10000000 OX9B DxCE: (0X00 
pl 

2 /* Data segment. */ 

23 .byte OxFF, OXFF, Ox00, Ox00, Ox00, Ox92, OxCF, 0x00 


24 LOCAL (gdt end): 


上 上 面 代码 厂 段 中 第 5 行 装 载 gdt 寄 存 咒 ，gdt 的 内 容 在 第 12~24 行 代码 中 定 
义 。 根 据 gdt 的 定义 可 见 ，gdt 中 定义 了 两 个 段 ， 一 个 是 代码 段 ， 男 外 一 个 是 
数据 段 。 这 两 个 段 的 基 址 都 是 0， 段 的 长 度 是 32 位 CPU 线性 地 址 空间 的 范 
图 ， 即 4GB。 这 两 个 段 的 唯一 区 别 是 代码 段 是 只 读 的 ， 而 数据 段 具 有 读 写 
权限 。 


继续 癌 下 看 第 7 行 代码 ， 其 中 有 一 个 字 节 的 "0xea"， 这 个 正 是 x86 指 令 集 
中 的 长 跳 转 指令 之 一 的 操作 码 ， 如 表 5-1 所 示 。 


表 5-1 x86 jmp 指令 说 明 (部 分 ) 


序号 操作 码 ( Opcode ) 指令 ( Instruction ) 操作 数 编码 方式 (Op/En ) 描 述 
根据 表 5-1 可 见 ， 指 令 jmp 的 操作 数 是 48 位 的 ， 前 16 位 是 代码 段 CS 的 内 
容 ， 后 32 位 是 指令 指针 EIP 的 内 容 。 


显然 ， 上 述 代 码 片段 中 跟 在 0xea 之 后 的 第 10 行 的 word 类 型 的 变量 就 是 
CS 段 的 内 容 ， 我 们 看 到 这 2 个 字 节 处 的 宏 CODE_SEGMENT 在 第 1 行 代码 处 
定义 ， 值 为 0x10， 展 开 二 进 制 为 : 


0001 0000 


在 保护 模式 下 ， 寄 存 器 CS 中 保存 的 是 段 选 择 子 (Segment Selector) ， 
其 格式 如 图 5-6 所 示 。 


15 对 温 下 划 


Index TI RPL 


图 5-6 段 选择 子 格式 


参照 图 5-6， 除 去 最 后 三 位 ， 那 么 CS$ 段 在 GDT 中 的 索引 就 是 二 进 制 的 
10， 十 进 制 的 2。 而 GDT 表 的 下 表 从 0 开始 ， 所 以 第 2 项 正好 是 代码 段 。 


第 9 行 的 long 类 型 的 变量 就 是 EIP 的 内 容 ， 这 个 值 是 在 函数 


grub_relocator32_boot 中 填充 的 ， 代 码 如 下 : 


grub-2.00/grub-core/lib/i386/relocator.c: 


grub errt tt grub' relocatkor32 Poot ane) 


{ 


grub relocator32 eip = state.eip; 


看 到 "state.eip" 是 不 是 很 熟悉 ? 没 错 ， 它 是 在 范 数 grub_linux_boot 中 设置 
的 ， 值 是 code32_start， 也 就 是 内 核 32 位 保护 模式 开始 的 地 方 。 由 此 可 见 ， 
函数 grub_relocator32_start 中 的 第 7~10 行 代码 ， 通 过 一 个 长 跳 转 ，GRUB 将 
控制 权 交 给 了 内 核 。 


5.2 解压 内 核 


根据 构建 内 核 时 的 分 机， 我 们 知道 ， 内 核 的 保护 模式 部 分 包括 非 压 纳 
部 分 以 及 压缩 部 分 ， 压 缮 部 分 才 征 内 核 正 间 运 转 时 的 部 分 ， 而 非 讨 缩 部 分 
只 是 一 个 过 客 ， 其 主要 作用 是 解压 内 核 的 压缩 部 分 ， 解 压 完 成 后 ， 非 压缩 
部 分 也 将 退出 历史 舞台 。 


内 核 的 解压 缩 过 程 几经 演进 ， 现 在 的 解压 过 程 不 再 是 首先 将 内 核 解压 
到 另外 的 位 置 ， 然 后 再 合并 到 最 终 的 目的 地 址 。 而 是 采用 了 所 谓 的 吏 地 解 
压 (in-place decompression) 方法 ， 内 核 解压 时 并 不 需要 解压 到 另外 的 位 
置 ， 从 而 避免 颖 善 其 他 部 分 的 数据 。 


以 不 可 重 定位 的 内 核 的 解压 过 程 为 例 ， 其 解压 过 程 如 图 5-7 所 示 。 


Location loaded by bootloader 


和 vmlinux.bin pd _bss 
Physical vmlinux 
Memory .bin.gz 
A 
startup 32 
input_data 
LOAD PHYSICAL ADDR vmliniix.bin 
Physical 
Memory 
3 z_input len 
z_ extract offset | 
A Me 
和 
| F200 decompress buffer 
7 中 一 二 六 
Physical : 
i uncompressed kernel 
六 z output len ,| 


LOAD PHYSICAL ADDR 
(where kernel runs from) 


图 5-7 不 可 重 定位 内 核 的 就 地 解压 过 程 


对 于 不 可 重 定位 内 核 ， 最 终 解 压 后 的 的 内 核 的 起 始 位 置 是 内 核 编译 时 
设 定 的 加 载 地址 ， 即 LOAD_PHYSICAL_ADDR。 虽 然 解 压 的 方式 是 就 地 解 
压 ， 但 是 为 了 安全 起 见 ， 解 压 过 程 所 需要 的 内 存 空间 并 不 完全 等 于 解压 后 
内 核 占 据 的 空间 ， 而 是 还 预 留 有 那么 一 点 点 安全 空间 。 所 以 这 个 解压 所 需 
的 空间 ， 即 图 中 标明 的 "In-place decompress buffer" 的 长 度 是 解压 后 内 核 的 长 


度 z_output_len 加 上 这 个 预 留 的 安全 空间 。 


为 了 确保 在 解压 时 ， 读 取 的 位 置 永远 在 写 入 的 位 置 的 前 面 。 内 核 首 先 
移动 到 这 个 解压 空间 的 最 后 。 那 么 内 核 如 何 才 能 确保 移动 到 这 个 空间 的 最 


后 呢 ? 内 核 只 需 从 LOAD_PHYSICAL_ADDR 向 后 移动 7_extract_offset， 就 
确保 了 内 核 映像 移动 到 了 这 个 解压 空间 的 最 后 


那么 z_extract_offset 以 及 图 5-7 中 的 几 个 数据 ， 包 括 解 压 后 内 核 的 长 度 
z_output_len 等 数据 ， 都 是 从 哪里 获取 的 呢 ? 这 些 数据 当然 是 压缩 内 核 的 时 
候 最 清楚 了 ， 因 此 这 些 早已 在 内 核 编译 时 ， 进 行 压缩 时 就 已 经 计算 好 了 ， 
定义 在 内 核 映 像 中 : 


linux-3.7.4/arch/x86/boot/compressed/piggy.s: 


.Section ".rodata..compressed",'"a",@progbits 
性 loBL Z input: Len 

z input len = 1721557 

‘globl z output. len 

Zz output len = 3421472 

globl z extract offset 

z extract offset = 0x1b0000 

.globl z extract offset negative 

Zz extract offset negative = -0x1lb0000 

.globl input data, input data end 

input data: 

.incbin "arch/x86/boot/compressed/vmlinux.bin.gz" 
input data end: 


piggy.S 中 定义 的 解压 内 核 时 需要 的 变量 包括 : 
1) z_input_len， 上 压缩 内 核 的 长 度 ， 即 vmlinux.bin.gz 的 长 度 。 
2) z_output_len， 内 核 解 压缩 后 的 长 度 。 


3) z_extract_offset， 进 行 就 地 解压 前 ， 相 对 于 解压 后 的 位 置 ， 内 核 映 
像 需要 向 后 移动 一 段 距 离 ， 为 解压 留 出 空间 ， 避 免 解 压 的 内 核 履 盖 了 压缩 
的 内 核 ，z_extract_offset 束 是 这 个 偏 移 的 大 小 。 


4) z_extract_offset_negative, 这 个 是 z_extract_offset 的 人 负数， 是 为 了 编 


程 方 便 定义 的 。 


5) input_data， 标 识 内 核 映像 中 ， 压 缩 部 分 的 起 始 位 置 。 


在 解压 缩 后 ， 非 压缩 部 分 根据 需要 可 能 还 要 对 内 核 进行 重 定位 符号 ， 
然后 跳 转 到 解压 后 的 内 核 的 入 口 startup_32。 接 下 来 ， 我 们 就 具体 讨论 一 下 


这 个 过 程 * 


5.2.1 移动 内 核 映 像 


1. 确 定 源 地 址 


前 面 讨 论 GRUB 时 ， 我 们 看 到 虽然 GRUB 按 照 引 导 协 议 的 规定 ， 将 内 核 
保护 模式 部 分 加 载 的 地 址 ， 即 code32_start 写 入 了 引导 参数 中 ， 但 是 只 有 内 
核 的 “真正 ”部 分 投入 运行 时 ， 内 核 才 复制 GRUB 保 存在 低 端 内 存 的 引导 参 
数 。 也 束 是 说 ， 这 个 临时 的 负责 解压 部 分 ， 并 没有 复制 GRUB 保 存 的 引导 参 
数 ， 因 此 ， 内 核 还 需要 目 己 计算 映像 被 加 载 的 地 址 。 内 核 使 用 下 面 的 代码 
获得 当前 被 Bootloader 加 载 的 地 址 : 


linux-3.7.4/arch/x86/boot/compressed/head 32.5s: 
ENTRY (startup 32) 

call TE 
ls Bopl %Sebp 

subl $1b, Sebp 


这 里 首先 解释 一 下 代码 片段 中 的 1f。1 后 面 的 f 霄 示 的 是 forward， 即 以 该 
条 指令 为 参照 ， 继 续 向 前 来 寻找 1 这 个 标号 ;如果 1 的 后 缀 是 bp， 则 意义 正好 


与 此 相反 。 


call 指 令 执行 时 ， 首 先 会 将 该 调用 返回 后 执行 的 下 一 条 指令 的 地 址 压 
栈 ， 这 里 就 是 标号 1 标识 的 指令 运行 时 的 地 址 。 执 行 了 call 指 令 后 ， 程 序 跳 
转 到 标号 1 所 在 的 代码 行 处 执行 ， 标 号 1 所 在 行 的 代码 将 栈 顶 的 内 容 弹 出 到 
寄存 器 ebp 中 。 而 此 时 栈 顶 的 内 容 恰 恰 是 执行 call 调 用 前 CPU 压 入 的 标号 1 处 
的 指令 的 地 址 ， 也 就 是 说 ， 寄 存 器 ebp 中 保存 的 就 是 标号 1 标识 的 指令 在 运 
行 时 所 在 的 地 址 。 接 下 来 ， 减 去 标号 1 这 行 代码 相对 于 程序 开头 处 的 偏 移 ， 
即 $1b， 就 获得 了 函数 startup_32 的 运行 时 地 址 。 而 函数 startup_32 就 是 内 核 
开头 ， 换 句 话 说 ， 就 是 获得 了 内 核 保护 模式 部 分 被 GRUB 实 际 加 载 的 地 址 。 


这 段 代 码 执行 后 ， 寄 存 右 ebp 中 保存 的 束 是 内 核 的 加 载 地 址 。 


2. 确 定 目 的 地 址 


内 核 映像 移动 的 目的 地 址 针对 内 核 是 否 文 持 重 定位 需要 区 别 计算 。 


(1) 内 核 被 编译 为 可 重 定位 


如 果 内 核 被 编译 为 可 重 定 位 ， 理 论 上 内 核 映像 被 加 载 的 地 址 就 可 以 作 
为 最 终 的 解压 目的 地 址 。 但 是 出 于 效率 角度 的 考虑 ， 所 以 还 要 进一步 检查 
Bootloader 加 载 的 地 址 是 否 符 合 内 核 的 对 齐 要 求 。 如 果 不 符合 要 求 ， 那 么 还 
要 按照 内 核 的 对 齐 要 求 修正 一 下 这 个 地 址 ， 然 后 再 将 其 作为 最 终 的 内 核 解 
压 的 目的 地 址 。 代 码 如 下 所 示 : 


linux-3.7.4/arch/x86/boot/compressed/head 32.S3: 


#ifdef CONFIG RELOCATABLE 


movl Sebp, %Sebx 
movl BP kernel alignment ($esi), %eax 
decl Seax 
addl Seax, Sebx 
notl Seax 
andl Seax, Sebx 
#else 
#endif 


/* Target address to relocate to for decompression */ 
addl $2 extract offset, %ebx 


在 上 面 代码 中 ，#f 代 码 块 的 目的 就是 进行 对 齐 修订 。 修 订 后 的 地 址 ， 
也 就 是 解压 内 核 的 目的 地 址 ， 保 存在 寄存 器 ebx 中 。 


然后 ， 将 内 核 解压 后 的 地 址 再 加 上 偏 移 z_extract_offset， 最 后 寄存 絮 ebx 
中 保存 的 即 是 内 核 映 像 在 解压 前 应 该 移动 到 的 位 置 。 


如 有 果 需 要 配置 一 个 可 重 定位 的 内 核 ， 则 可 按 如 下 步骤 进行 : 


1) 执行 make menuconfig， 出 现 如 图 5-8 所 示 的 界面 。 


[*] Enable loadable module support ---> 
-*- Enable the block layer ---> 


Processor type and features ---> 
Power management and ACPI options ---> 
Bus options (PCI etc.) ---> 


图 5-8 配置 可 重 定位 内 核 (1) 


2) 在 图 5-8 中 ， 选 择 菜单 项 "Processor type and features"， 出 现 如 图 5-9 
所 示 的 界面 。 


[ ] kexec system call 


kernel crash dumps 
uild a relocatable kernel 


(9x16969096) Alignment vaLue to which kerne 
[ ] Support for hot-pluggable CPUs 


图 5-9 配置 可 重 定位 内 核 (2) 
3) 在 图 5-9 中 ， 选 择 "Build a relocatable kernel"。 


在 内 核 3.7.4 版 本 中 默认 对 齐 为 0x1000000， 当 然 也 可 以 通过 配置 内 核 进 
行 修改 。 


(2) 内 核 不 支持 重 定位 


如 果 内 核 没 有 被 编译 为 可 重 定位 ， 那 么 表明 内 核 不 允许 将 其 加 载 到 其 
他 位 置 ， 必 须要 加 载 到 LOAD_PHYSICAL ADDR， 因 此 内 核 的 解压 目的 地 
址 就 是 LOAD_PHYSICAL_ADDR。 代 码 如 下 : 


linux-3.7.4/arch/x86/boot/compressed/head 32.S 
#ifdef CONFIG RELOCATABLE 
#else 

movl $LOAD PHYSICAL ADDR, $ebx 


#endif 


/* Target address to relocate to for decompression */ 
addl $z extract offset, Yebx 


然后 ， 将 解压 的 目的 地 址 偏 移 z_extract_offset， 最 后 ， 寄 存 器 ebx 中 保存 
的 即 是 内 核 映 像 在 解压 前 应 该 移动 到 的 位 置 。 


变量 LOAD_PHYSICAL_ADDR 是 内 核 编 译 时 指定 的 加 载 地 址 。 其 定义 
如 下 : 


linux-3.7.4/arch/x86/include/asm/boot.h 
#define LOAD PHYSICAL ADDR ( (CONFIG PHYSICAL START 并 
+ (CONFIG PHYSICAL ALIGN - 1)) \ 
区 ~ (CONFIG PHYSICAL _ ALIGN 3 1)) 
可 见 ，LOAD _PHYSICAL _ADDR 就 是 内 核 配置 选项 
CONFIG_PHYSICAL_START 按 照 内 核 的 对 齐 要 求 修订 后 的 值 。 


由 这 里 可 见 ， 即 使 内 核 不 允许 重 定位 ， 那 么 事实 上 最 后 内 核 解压 后 的 
地 址 也 是 符合 内 核 的 对 齐 要 求 的 ， 因 为 这 里 已 经 对 编译 时 指定 的 加 载 地 址 
进行 了 对 齐 处 理 。 


内 核 3.7.4 版 本 的 默认 加 载 地 址 是 0x1000000， 用 户 可 以 通过 配置 指定 内 
核 加 载 的 物理 地 址 ， 步 又 如 下 ; 


1) 执行 make menuconfig， 出 现 如 图 5-10 所 示 的 界面 。 


[*] Enable loadable modutLe support ---> 
-*- Enable the block layer ---> 


Processor type and features ---> 
Power management and ACPI options ---> 
Bus options (PCI etc.) ---> 


图 5-10 更 改 内核 加 载 地址 (1) 


2) 在 图 5-10 中 ， 选 择 荣 单项 "Processor type and features"， 出 现 如 图 5- 
11 所 示 的 界面 。 


[ ] kexec system call 
kernel crash dumps 


sical address where the kernel is Loaded (NEW) 
[ ] Build a relocatable kernel 


图 5-11 更 改 内 核 加 载 地 址 (2) 


3) 设置 内 核 加 载 地 址 依赖 于 CONFIG_EXPERT 或 者 
CONFIG_CRASH_DUMP， 所 以 如 果 要 修改 内 核 依赖 地 址 ， 必 须 选 择 这 两 
项 中 的 一 项 。 可 以 在 图 5-11 中 选中 "kernel crash dumps"， 即 
CONFIG_CRASH_DUMP， 在 该 配置 项 的 下 面 即 可 出 现 修改 内 核 加 载 地 址 
的 配置 项 "Physical address where the kernel is loaded"， 修 改 这 一 项 的 值 即 可 
达到 修改 内 核 加载 地 址 的 目的 。 


3. 移 动 内 核 映像 


产地 址 和 目的 地 址 确定 后 ， 内 核 映 像 束 开始 了 移动 过 程 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/boot/compressed/head 32.3: 


01 pushl Sesi 

02 leal (_bss-4) (%ebp), %esi 

03 leal ( bss-4) (%ebx), gedi 

04 movl $( bss - startup 32), $%ecx 


05 shrl $2, %Secx 


06 std 


07 rep movsl 

08 GL 

09 popl Sesi 

10 i 

下 leal relocated(%ebx), %Seax 
12 jmp *%eax 

13 ENDPROC (startup 32) 

14 

15 .text 


16 relocatead: 


在 上 述 代码 中 ， 符 号 _bss 在 链接 vmlinux.bin 时 定义 在 bss 段 的 开头 。BSS 
段 被 链接 在 vmlinux.bin 的 最 后 ， 而 它 在 内 核 映 像 文 件 中 并 不 占据 空间 ， 因 
此 ， 符 号 _bss 的 地 址 就 是 内 核 保护 模式 的 末尾 。 


寄存 融 esj 是 你 存 移 动 指令 的 源 地 址 的 ， 第 2 行 代码 吏 是 设置 这 个 寄存 央 
的 值 ， 表 达 式 : 


( bss-4) (%ebp) 


展开 后 如 下 : 


Sebp + bss - 4 


而 寄存 絮 ebp 中 保存 的 值 是 内 核 加 载 的 地 址 ， 所 以 "%ebp+_bss" 即 为 内 核 
的 末尾 地 址 ，-4 的 目的 当然 是 为 第 一 次 复制 留 出 4 字 市 的 空间 。 


类 似 的 ， 第 3 行 代码 是 设置 保存 移动 指令 的 目的 地 址 的 寄存 髓 edi。 因 为 
寄存 天 ebx 中 保存 移动 后 的 内 核 地 址 ， 所 以 edi 中 的 值 最 后 设置 为 移动 后 的 内 


核 的 末尾 地 址 ， 并 为 第 一 次 复制 留 出 4 字 节 的 空间 。 


同 理 ， 读 者 回忆 一 下 vmlinu.bin 的 构建 ， 链 接 脚 本 指定 将 函数 startup_32 
链接 在 vmlinux.bin 的 最 开头 ， 因 此 ， 在 第 4 行 代码 中 ，"bss-startup_32" 就 是 
内 核 以 字 节 为 单位 的 长 度 了 。 因 为 ， 一 次 复制 4 字 节 ， 所 以 代表 移动 次 数 的 
寄存 器 ecx 需 要 右 移 两 位 ( 即 除 以 4) 。 


第 6 行 代 码 中 ， 指 令 std 的 目的 是 表示 每 移动 一 次 ，esi 和 edi 分 别 减 一 〈4 
字 节 ) ， 也 就 是 说 复制 是 从 内 核 尾 部 向 着 头 部 的 方向 复制 。 


内 核 移动 结束 后 ， 显 然 需 要 重新 装载 指令 指针 EIP 的 值 ， 跳 转 到 移动 后 
的 内 核 中 继续 执行 。 这 里 是 通过 jmp 指 令 修改 指令 指针 的 ， 即 第 12 行 代码 ， 
这 条 语句 的 目的 是 跳 转 到 移动 后 的 内 核 映像 中 标号 relocated 处 继续 执行 。 


5.2.2 ”解压 


完成 内 核 移动 后 ， 下 一 步 束 要 开始 解压 内 核 了 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/boot/compressed/head 32.S: 


a1 leal z extract offset negative(%ebx), %ebp 

02 /* push arguments for decompress kernel: */ 
03 pushl Sebp /* output address */ 

04 pushl $z input len /* input len */ 

05 leal input data(%ebx), %eax 

06 pushl Seax /* input data */ 

07 leal boot heap (%ebx), %eax 

08 pushl Seax /* heap area */ 

09 pushl Sesi /* real mode pointer */ 

10 Gall decompress kernel 


我 们 看 人 到， 在 head_32.S 中 ， 调 用 函数 decompress_kernel 解 压 内 核 ， 见 
第 10 行 代码 。decompress_kernel] 是 用 C 语 言 编 写 的 ， 其 函数 定义 在 misc.c 
中 : 


linux-3.7.4/arch/x86/boot/compressed/misc.c: 
asmlinkage void decompress kernel (void *rmode, memptr heap, 
unsigned char *input data, 


unsigned long input len, 
unsigned char *output) 


我 们 结合 函数 decompress_kernel 来 看 看 文件 head_32.S 中 的 几 个 关键 参 
数 : 


1) 函数 decompress_kernel 的 最 后 一 个 参数 output 是 内 核 解 压 的 目的 地 
址 ， 这 个 应 该 是 第 一 个 压 栈 的 参数 ， 见 head_32.S 代 码 第 1~3 行 。 在 前 面 讨论 
移动 内 核 时 ， 我 们 看 到 ， 寄 存 侣 ebx 中 保存 的 是 内 核 移动 后 的 地 址 ， 而 根据 
piggy.S，z_extract_offset_negative 就 是 z_extract_offset 的 人 负数， 所 以 表达 式 


z extract offset negative (%ebx) 


相当 于 


yeDX - Zz extract offset 


党 


照 独 5-7， 显 然 ， 这 怠 是 内 核 解压 的 目的 地 址 。 


2) 函数 decompress_kernel 的 参数 ipput_len 表 示 压 缩 的 内 核 映 像 的 长 
， 这 个 变量 对 应 piggyS 中 定义 的 z_input_len， 这 是 第 2 个 需要 压 栈 的 参 
数 ， 见 head_32.S 代 码 片 段 第 4 行 。 


间 


3) 男 数 decompress_kernel 的 参数 input_data 表 示 压 缩 的 内 核 映 像 的 开 
头 ， 对 应 piggy.S 中 定义 的 input_data， 这 是 第 3 个 需要 压 栈 的 参数 ， 见 
head_32.S 代 码 片 段 第 5 行 。 


具体 解压 算法 ， 我 们 不 再 分 机 ， 读 者 如 采 有 兴趣 ， 可 目 行 阅读 代码 。 


5.2.3” 重 定位 


根据 下 面 的 内 核 链接 脚本 片段 可 见 ， 内 核 中 指令 和 数据 的 运行 时 地 址 
是 假定 内 核 被 解压 到 物理 地 址 LOAD_PHYSICAL _ADDR 处 而 分 配 的 ， 我 们 
称 这 个 假定 地 址 为 理论 加 载 地 址 。 


linux-3.6.6/arch/x86/kernel/vmlinux.1ds.s: 


SECTIONS 


{ 


#ifdef CONFIG X86 32 
. = LOAD OFFSET + LOAD PHYSICAL ADDR; 


phys_startup 32 = startup 32 - LOAD OFFSET,; 
#else 


} 


如 果 内 核 被 配置 为 可 重 定位 的 ， 那 么 尽管 内 核 在 引导 协议 中 会 将 希望 
加 载 的 地 址 (pref_address) 设置 为 LOAD_PHYSICAL_ADDR， 如 下 代码 : 


linux-3.7.4/arch/x86/boot/header.s: 


pref address: .quad LOAD PHYSICAL ADDR # preferred load addr 


但 是 内 核 并 不 能 确保 Bootloader 将 内 核 一 定 加 载 到 内 核 建议 的 
LOAD_PHYSICAL_ADDR。 如 果 Bootloader 实 际 加 载 地 址 与 理论 加 载 地 址 
不 同 ， 那 么 内 核 需 要 进行 重 定 位 。 


对 于 可 重 定位 内 核 ， 内 核 目 身 包 含 一 个 工具 relocs。 在 编译 内 核 的 最 
后 ，relocs 将 vmlinux 中 需要 重 定位 的 符号 导出 ， 写 入 vmlinux.relocs， 然 后 
build 将 其 链接 在 内 核 的 最 后 。 简 单 来 讲 ，vmlinux.relocs 丈 是 一 个 数组 ， 
一 个 元 素 记 录 的 就 是 一 个 需要 修订 的 位 置 。 


head_32.S 中 重 定位 的 代码 片段 如 下 : 


linux-3.7.4/arch/x86/boot/compressed/head 32.3S: 


01 #if CONFIG RELOCATABLE 


leal z_output len(%ebp), %edi 
movl Sebp, %ebx 
subl $LOAD PHYSICAL ADDR, Sebx 
jz 2f /* Nothing to be done if loaded at compiled addr 
1:; subl $4, Sedi 
movl (Sedi), %Secx 
testl Secx, Secx 
] 芭 ”次 二 
addl Sebx, -__PAGE OFFSET(%ebx, %ecx) 
jmp 1b 
2 
#endif 
jmp *%ebp 


该 代码 片段 执行 的 主要 操作 如 下 : 


wk 


1) 首先 需要 判断 内 核 是 否 需 要 重 定位 ， 见 代码 第 5~7 行 。 在 前 面 为 解 
压缩 函数 准备 参数 时 ， 寄 存 器 ebp 中 记录 了 内 核 解 压 后 的 地 址 ， 所 以 这 两 行 
代码 的 目的 就 是 比较 内 核 解 压 后 的 地 址 与 内 核 理论 加 载 地 址 
LOAD_PHYSICAL_ADDR。 如 果 相 同 ， 那 么 无 须 进 行 重 定位 ， 
号 2 处 ， 也 就 是 跳 过 了 标号 1 和 标号 2 之 间 的 重 定位 代码 。 


直接 跳 到 标 


2) 如 果 需 要 重 定位 ， 那 么 首先 需要 找到 重 定位 表 vmlinux.relocs， 见 第 
3 行 代码 。 在 编译 时 ， 内 核 构建 脚本 将 重 定 位 表 链 接 在 映像 的 最 后 ， 而 
z_output_len 代 表 内 核 解 压 后 的 长 度 ， 因 此 ，%ebp+z_output_len 指 向 的 就 古 
重 定 位 表 的 末尾 。 


3) 找到 重 定位 表 后 ， 就 可 以 进行 重 定位 了 ， 代 码 第 9~14 行 从 后 向 前 遍 
历 重 定位 表 ， 逐 项 进行 修订 。 其 中 第 9~12 行 代码 判断 重 定位 是 否 已 经 完 
成 ， 重 定位 表 以 0 开头 ， 所 以 ， 当 某 一 项 的 值 为 0 时 ， 了 就 说 明 已 经 到 了 重 定 
位 表 的 表 头 ， 所 有 需要 重 定位 的 条 目 已 经 完成 。 具 体 的 修订 算法 非常 直 
接 ， 融 是 在 每 个 修订 的 位 置 ， 加 上 内 核实 际 加 载 的 地 址 与 理论 加 载 地 址 的 
过 值 ， 见 第 13 行 代码 。 但 是 这 行 指令 的 操作 数 使 用 了 相对 复杂 一 点 的 寻 址 
方式 ， 而 且 两 次 出 现 了 寄存 器 ebx， 所 以 容易 让 人 困惑 。 


首先 来 看 一 下 寄存 器 ebx 的 值 。 事 实 上 ， 在 执行 第 6 行 代码 时 ， 内 核实 
际 的 加 载 地 址 与 理论 加 载 地 址 的 差 值 已 经 被 保存 到 了 寄存 器 ebx 中 。 也 就 是 
说 ， 用 来 修订 的 差 值 已 经 准备 就 绪 。 那 么 显然 ， 第 13 行 代码 中 指令 addl 的 第 
二 个 操作 数 : 


- PAGE OFFSET(%ebx, %ecx) 


就 是 需要 修订 的 位 置 ， 我 们 将 其 展开 : 


Sebx + Secx - PAGE OFFSET 


为 了 看 得 更 清楚 一 点 ， 我 们 换个 写法 : 


(Secx - PAGE OFFSET) + %ebx 


我 们 来 分 析 这 个 表达 式 ， 寄 存 器 ecx 就 像 一 个 局 部 变量 ， 临 时 存储 重 定 
位 表 中 每 一 项 ， 即 需要 重 定位 的 位 置 ， 那 么 为 什么 要 从 ecx 中 人 刨 除 
PAGE_OFFSET 呢 ?这 个 问题 的 根源 就 在 于 重 定位 表 vmlinux.relocs 中 记录 
的 修订 位 置 使 用 的 是 虚拟 地 址 。 


内 核 为 了 占据 3GB 以 上 的 进程 地 址 空间 ， 所 以 在 编译 时 ， 链 接 器 为 每 
个 符号 的 地 址 增加 了 3GB 的 偏 黎 ， 也 就 是 这 里 的 _PAGE_OFFSET。 在 内 核 
运行 时 ， 页 式 映 射 会 将 这 个 逻辑 上 的 偏 移 消除 ， 将 符号 映射 到 真正 的 物理 
地 址 。 


但 此 时 的 麻烦 是 ，CPU 疝 未 开局 页 式 映 射 ， 而 且 GRUB 将 CPU 设置 工作 
在 平坦 内 存 模 型 下 ， 段 基 址 都 为 0， 虚 拟 地 址 经 过 MMU 了 映射 后 ， 将 原封 不 
动 地 转换 为 物理 地 址 。 举 个 例子 ,假设 内 核 最 终 加 载 到 了 16MB 人 处 ， 那 么 内 
核 开 头 的 虚拟 地 址 是 0xc1000000， 假 设 这 里 需要 修订 ， 那 么 重 定位 表 中 记 
杂 的 修订 位 置 是 0xc1000000。 当 进行 重 定位 时 ， 如 果 不 做 任何 处 理 ， 这 个 
地 址 经 过 MMU 转 换 后 的 物理 地 址 依然 为 0xc1000000， 显 然 多 了 3GB 的 偏 
移 。 因 此 ， 重 定位 代码 需要 事先 将 这 个 偏 移 消除 掉 。 这 就 是 在 寄存 器 ecx 的 
基础 上 再 减 去 ”PAGE_OFFSET 的 原因 。 


但 是 仅仅 减 去 _PAGE_OFFSET 还 不 够 ， 不 仅 修订 位 置 处 的 内 容 需 要 进 
行 修订 ， 修 订 位 置 本 身 也 发 生 了 变化 ， 如 图 5-12 所 示 ， 上 面 的 虚线 表示 的 是 
内 核 理论 加 载 的 地 址 ， 下 面 的 实 线 表示 的 是 内 核实 际 加 载 的 地 址 。 


uncompressed 
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图 5-12 重 定位 位 置 的 变化 


因此 ， 修 订 位 置 本 喘 也 需要 进行 修订 。 修 订 位 置 本 和 吴 的 偏 移 就 是 内 核 
理论 加 载 位 置 和 实际 加 载 位 置 的 差 值 ， 而 这 个 差 值 已 经 保存 在 寄存 器 ebx 


中 ， 这 就 是 为 什么 修订 位 置 除了 减 去 ”PAGE_OFFSET 外 ， 又 加 上 ebx 的 原 
因 。 


重 定位 完成 之 后 ， 跳 转 到 解压 后 的 内 核 起 始 地 址 处 继续 执行 ， 见 重 定 
位 代码 片段 中 的 第 18 行 。 


5.3 内核 初始 化 


虽然 操作 系统 的 功能 包括 进程 管理 、 内 存 管理 、 设 备 管理 等 ， 但 是 操 
作 系 统 的 终极 目标 是 创造 一 个 环境 ， 承 载 进程 。 但 是 由 于 进程 运行 时 ， 可 
能 需要 和 各 种 外 设 打交道 ， 因 此 ， 操 作 系统 初始 化 时 ， 也 会 将 这 些 外 设 等 
子 系统 进行 初始 化 ， 这 也 导致 内 核 初 始 化 过 程 异 常 复 洒 。 昌 然 这 些 过 程 很 
重要 ， 但 是 忽略 它们 并 不 妨碍 理解 操作 系统 的 本 质 。 本 节 我 们 并 不 关心 这 
些 子 系统 的 初始 化 ， 比 如 USB 系 统 是 如 何 初 始 化 的 ， 我 们 只 围绕 进程 来 讨 

论 内 核 相 关 部 分 的 初始 化 。 


5.3.1 初始 化 虚拟 内 存 


相对 于 单 任 务 来 说 ， 多 任务 的 好 处 无 需 资 言 ， 但 是 多 任务 也 对 操作 系 
统 提出 了 更 多 的 要 求 ， 其 中 一 个 主要 问题 吏 是 如 何在 多 个 任务 间 互 不 干扰 
地 共享 同一 物理 内 存 。 正 如 Dennis DeBruler 说 过 的 经 典 的 一 句 话 : 计算机 科 
学 中 所 有 问题 都 可 以 通过 多 一 个 间接 层 来 解决 。 现 代 操 作 系统 设计 了 虚拟 
内 存 机 制 文 持 多 任务 。 


通过 虚拟 内 存 机 制 ， 多 个 进程 之 间 束 可 以 和 平 共 译 物理 内 存 。 每 个 进 
程 都 有 了 目 己 独立 的 虚拟 地 址 空间 ， 感 觉 束 像 目 己 独占 物理 内 存 一 样 。 在 
某 一 个 进程 中 访问 任何 地 址 都 不 可 能 访问 到 另外 一 个 进程 的 数据 ， 这 使 得 
任何 一 个 进程 由 于 执行 错误 指令 或 恶意 代码 导致 的 非法 内 存 访问 都 不 会 总 
外 改写 其 他 进程 的 数据 ， 也 不 会 影响 其 他 进程 的 运行 ， 从 而 保证 整个 系统 


的 稳定 性 。 进 程 本 身 不 必 关 心虚 拟 地 址 是 如 何 映射 到 物理 内 存 以 及 存储 在 
物理 内 存 的 什么 位 置 ， 完 全 由 操作 系统 蔡 其 打 理 。 


为 了 支持 虚拟 内 存 ， 操 作 系统 不 必 拆 军 奋 战 。 现 代 的 处 理 右 几乎 部 从 
硬件 的 角度 设计 了 支持 虚拟 内 存 的 机 制 ， 以 x86 架 构 为 例 ， 其 引入 了 MMU 
单元 。 但 是 与 其 他 CPU 几乎 全 部 采用 分 页 机 制 文 持 实现 虚拟 内 存 不 同 ， 对 
于 x86 体 系 架构 来 说 ， 由 于 历史 的 原因 ， 事 情 有 点 复业。 最 初 ，8086 的 寄存 
絮 是 16 位 的 ， 可 以 寻 址 64KB 内 存 ， 为 了 在 不 改变 寄存 器 和 指令 位 数 的 情况 
下 支持 更 大 的 寻 址 空间 ，Intel 的 工程 师 们 设计 了 一 种 段 式 寻 址 机 制 。 后 来 ， 
为 了 向 后 兼容 ， 也 就 是 保证 为 更 早 的 体系 结构 开发 的 程序 依旧 可 以 在 新 的 
体系 架构 上 运行 ， 在 后 续 的 x86 系 列 处 理 作 上，Intel 保 留 了 段 式 寻 址 机 制 ， 
而 且 不 能 关闭 段 式 机 制 。 因 此 ， 对 于 x86 架 构 来 说 ， 虚 拟 内 存 向 物理 内 存 的 
转换 需要 经 过 两 个 阶段 ， 如 图 5-13 所 示 。 
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图 5-13 x86 架 构 虚 拟 内 存 同 物理 内 存 转换 


1) 逻辑 地 址 转换 为 线形 地 址 。CPU 将 逻辑 地 址 发 送 给 MMU。 辑 地 
址 分 为 两 部 分 ，16 位 的 段 选 择 子 和 32 位 的 段 内 偏 移 。 当 把 这 48 位 地 址 传 给 
MMU 时 ，MMU 中 的 分 段 单元 根据 16 位 段 选 择 子 ， 从 GDT 表 中 获取 对 应 
段 ， 取 出 段 基 址 ， 再 加 上 人 逻辑 地 址 中 的 32 位 的 偏 黎 ， 惑 形成 了 线性 地 址 。 


2) 线形 地 址 转换 为 物理 地 址 。 分 段 单元 将 线性 地 址 发 送 给 分 页 单元 ， 
分 页 单元 通过 页 表 ， 将 线性 地 址 转换 为 物理 地 址 。 


通过 虚拟 内 存 ， 同 一 个 虚拟 地 址 可 以 映 冉 到 不 同 的 物理 内 存 。 这 也 是 
多 个 进程 共享 同一 个 物理 内 存 的 理论 基础 ， 如 图 5-14 所 示 。 
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图 5-14 虚拟 内 存 映射 


显然 ， 为 了 文 持 MMU 进 行 地 址 转换 ， 操 作 系 统 需要 为 MMU 准 备 GDT 
以 及 页 表 ， 下 面 我 们 就 讨论 这 两 个 过 程 。 


1. 创 建 GDT 


分 段 机 制 是 x86 系 列 处 理 紫 演变 发 展 过程 中 癌 后 兼容 的 产物 ， 更 重要 的 
是 ， 页 式 映 射 已 经 完全 可 以 非常 好 地 支持 虚拟 内 存 机 制 了 ， 除 了 增加 实现 


的 复杂 度 ， 分 段 机 制 已 经 没有 存在 的 意义 了 。 除 了 IA 架 构 ， 其 他 体系 结构 
几乎 没有 使 用 段 机 制 的 。 但 是 为 了 向 后 兼容 ， 叉 不 能 关闭 段 机 制 ，IA 架 构 
提出 了 一 种 特殊 的 内 存 管 理 模 型 一 一 平坦 内 存 模 型 (flat model) ， 如 图 5- 


15 所 示 。 
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图 5-15 平坦 内 存 模 型 


当 使 用 平坦 内 存 模型 时 ， 所 有 段 的 基 址 均 为 0， 段 长 为 线性 地 址 空间 的 
整个 长 度 。 读 者 可 能 心 存 疑问 : 如 果 段 基 址 相同 ， 那 么 同一 进程 的 不 同 段 
之 间 的 地 址 是否 会 发 生 重 县 ? 这 点 大 可 不 必 担 心 ， 虽 然 各 个 段 的 段 基 址 都 
从 0 开始 ， 但 是 在 编译 时 ， 链 接 亏 会 通过 段 内 偶 移 控制 各 个 段 的 内 容 不 会 披 
此 和 窗 坊 。 


平坦 内 存 模型 就 像 功 夫 中 的 太极 ， 将 分 段 这 个 "麻烦 "化 解 于 无 形 。 在 
平坦 内 存 模型 下 ，MMU 中 的 分 段 单元 对 地 址 的 变换 没有 任何 影响 ， 编 译 好 


的 二 进 制 程序 中 的 偏 移 地 址 (或 者 称 为 虚拟 地 址 ) 完全 等 同 于 线性 地 址 。 
平坦 内 存 模型 不 仪 人 简化 了 操作 系统 中 的 内 存 管 理 ， 而 且 也 大 大 降低 了 编译 
器 和 链接 器 实现 的 复杂 度 。 


本 质 上 ， 平 坦 内 存 模型 并 不 是 一 种 什么 特殊 的 模式 ， 只 是 保护 模式 下 
的 一 种 特例 而 已 ， 其 中 的 关键 就 在 于 段 的 基 址 和 上 段 的 长 度 的 设置 。 在 内 核 
初始 化 代码 中 ， 有 两 处 设置 并 加 载 了 GDT。 第 一 处 是 函数 startup_32， 代 码 
如 下 : 


linux-3.7.4/arch/x86/kernel/head 32.5S: 


01 ENTRY (startup 32) 


02 si 

03 testb $(1<<6), BP loadflags (%esi) 

04 jniz 2E 

05 

06 lgdt Pa(boot gdt descr) 

07 人 

08: 2Z5 

09 RN 

10 boot gdt descr: 

.word BOOT DS+7 

2 .long boot gqt - _ PAGE OFFSET 

UL 

14 ENTRY (boot gdt) 

15 .fill GDT ENTRY BOOT CS,8,0 

Le .quad 0x00cf9a000000ffff /* kernel 4GB code at 0x00000000 */ 
7 .quad 0x00cf92000000ffff /* kernel 4GB data at 0x00000000 */ 


内 核 首 先 检查 引导 协议 中 的 loadflags 的 第 6 位 ， 即 KEEP_SEGMENTS 
位 。 如 果 Bootloader 没 有 设置 这 一 位 ， 那 么 内 核 需 要 重新 装载 各 个 段 寄 存 
器 ， 包 括 GDT 寄 存 器 gdtr， 第 6 行 代码 就 是 重新 设置 GDT 寄 存 器 gdtr， 使 其 指 


癌 boot_gdt_descr， 而 boot_gdt_descr 中 又 包含 了 符号 boot_gdt。 我 们 来 看 一 
下 内 核 中 的 这 两 个 符号 的 值 : 


vita@baisheng:/vita/build/linux-3.7.4$ readelf -s vmlinux \ 

| grep boot gdt 
24312: c1378d86 0 NOTYPE GLOBAL DEFAULT 13 boot gdt descr 
29580: c1378dc0 0 NOTYPE GLOBAL DEFAULT 13: 了 CO :gat 


这 两 个 符号 的 值 均 以 C 开 头 ， 显 然 都 是 虚拟 地 址 了 。 但 是 ， 问 题 是 此 时 
CPU 尚未 开局 分 页 ， 所 以 不 能 使 用 虚拟 地 址 寻 址 ， 而 只 能 使 用 物理 地 址 寻 
址 。 所 以 在 第 6 行 代码 中 ， 使 用 宏 pa 将 符号 boot_gdt_descr 的 虚拟 地 址 转化 为 
物理 地 址 ， 稍 后 我 们 会 具体 讨论 这 个 宏 ， 其 主要 作用 就 是 将 符号 中 的 3GB 
偏 移 去 控 。 同 理 ， 注 意 第 12 行 代码 ， 在 使 用 符号 boot_gdt 时 ， 也 去 除了 3GB 
偏 移 。 因 此 ， 此 后 直到 下 一 次 重新 装载 ， 寄 存 右 gdtr 中 将 始终 记录 的 是 符号 
boot_gdt_descr 的 物理 地 址 。 


但 是 在 CPU 开 启 了 分 页 后 ， 应 该 使 用 虚拟 地 址 寻 址 了 。 所 以 ， 在 开启 
分 页 后 ， 内 核 还 需要 重新 装载 寄存 器 gdtr， 将 其 中 的 物理 地 址 奉 换 为 GDT 描 
述 符 的 虚拟 地 址 ， 这 束 是 内 核 两 次 加 载 gdtr 寄 存 需 的 原因 。 因 为 这 个 
boot_gdt 只 是 临时 的 GDT， 够 用 束 可 以 了 ， 所 以 我 们 看 到 boot_gdt 非 常 侧 
单 。 


内 核 中 第 二 次 加 载 寄存 右 gdtr 的 代码 如 下 : 


linux-3.7.4/arch/x86/kernel/head 32.S3: 


01 ENTRY (startup_32) 


02 a 

03 movl $pal(initial page table), %eax 

04 mOV1 %Seax,%cr3 /* set the page table pointer.. */ 
05 moOV] %cr0, Seax 

06 orl $X86 CRO_ PG, Seax 

07 movl Seax,%gScr0 /* ..and set paging (PG) bit */ 

08 i 

09 lgdt early gdt descr 

10 i 

11 ENTRY (early gdt descr) 

a be .word GDT ENTRIES*8-1 

13 .long gdt page /* Overwritten for secondary CPUs */ 
14 


在 开局 分 页 机 制 后 ， 虚 拟 内 存 已 经 初始 化 完成 ， 内 核 不 必 再 使 用 汇编 
语言 将 虚拟 地 址 使 用 宏 pa 手 工 转 化 为 物理 地 址 了 ， 可 以 直接 使 用 符号 的 虚 
拟 地 址 了 ， 如 第 9 行 代码 使 用 的 符号 early_gdt_descr 以 及 第 13 行 代码 使 用 的 
从 号 gdt_page， 使 用 的 全 部 是 符号 的 虚拟 地 址 ，MMU 会 完成 虚拟 地 址 到 物 
理 地 址 的 转换 。 换 句 话说 ， 内 核 不 必 再 使 用 汇编 语言 “精确 ”地 指挥 CPUT 了 ， 
可 以 使 用 更 容易 维护 的 C 语 言 7 了 ， 所 以 内 核 使 用 C 语 言 重新 定义 了 更 完善 的 
GDT: 


linux-3.7.4/arch/x86/kernel/cpu/common.c: 


DEFINE PER CPU PAGE ALIGNED(struct gdt page, gdt page) = 


{ .gat = { 
[GDT_ ENTRY KERNEL CS] = GDT ENTRY INIT(0xc09a, 0, Oxfffff), 
[GDT ENTRY KERNEL DS] = GDT ENTRY INIT (0xc092, 0 MEETEEE). 
[GDT_ ENTRY DEFAULT USER CS] = GDT ENTRY INIT(0xc0Ofa，0， 


Oxfffff), 
[GDT_ ENTRY DEFAULT USER DS] = GDT ENTRY INIT(0xc0f2, 0, 
OxfEEEE)., 


安 GDT_ENTRY _INIT 用 来 构建 一 个 全 局 描述 符 ， 定 义 如 下 : 


linux-3.7.4/arch/x86/include/asm/desc defs.h: 


#define GDT ENTRY INIT(flags, base, limit) { { {\ 


.a = ((limit) & Oxffff) | (((base) & Oxffff) << 16), \ 
.b= (((base) & Oxff0000) >> 16) | (((flags) & Oxf0ff) << 8) | \ 
((limit) & Oxf0000) | ((base) & Oxff000000), \ 
让 


< 个 


参照 图 5-16 所 示 的 段 描述 符 的 定义 。 
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图 5-16 段 描述 符 定 义 


可 见 ， 所 有 段 的 基 址 都 是 0(， 上 限 都 是 0xfffff。 正 如 我 们 前 面 讨论 的 ， 
Linux 使 用 了 平坦 内 存 模型 。 各 个 段 仅 有 属性 有 一 些 差 别 ， 如 表 5-2 所 示 。 


表 5-2 内核 代码 段 和 数据 段 的 属性 


Segment/Flags 


Type 
Kernel CS / 0xc09a 1010 
Kernel DS / 0xc092 0010 
User CS / 0xc0fa 1010 
User DS / 0xc0f2 0010 


其 中 不 同 的 字段 是 DPL 和 Type 。 


DPL 表 示 段 的 特权 级 。 内 核 的 代码 段 和 数据 段 的 特权 级 是 最 高 的 0， 而 
用 户 代码 和 数据 段 的 特权 级 是 最 低 的 3。 显 然 ， 从 保护 的 角度 ， 内 核 将 段 划 
分 为 内 核 空间 和 用 户 空间 。 


男 外 一 个 不 同 的 是 Type。 对 于 代码 段 ， 包 括 内 核 和 用 户 空间 的 ， 其 类 
型 为 1010b， 表 示 只 具有 可 读 权限 。 数 据 段 的 类 型 为 0010bp， 表 示 具 有 读 写 
权限 。 显 然 这 也 是 从 保护 角度 考虑 的 ， 试 图 写 代 码 段 将 激发 Segment Fault 类 


型 的 错误 。 


理论 上 ， 如 果 使 用 平坦 内 存 模型 ，GDT 中 只 定义 一 个 段 描 述 符 就 可 以 
了 ， 所 有 段 都 使 用 这 一 个 段 描述 符 ， 但 是 出 于 保护 的 目的 ， 代 码 征 不 允许 
随意 改写 的 ， 因 此 内 核定 义 了 代码 段 和 数据 段 。 同 样 出 于 保护 的 目的 ， 内 
核 是 不 允许 用 户 空 间 的 程序 随意 访问 内 核 空间 的 ， 所 以 内 核 又 定义 了 内 核 
段 和 用 户 段 。 最 终 内 核定 义 了 内 核 代 码 段 、 内 核 数 据 段 、 用 户 代码 段 和 用 
户 数据 段 。 


正如 同 在 平坦 内 存 模型 下 ， 链 接 郁 通过 侦 移 地 址 控制 代码 和 数据 占据 
的 空间 ， 链 接 器 也 需要 通过 偏 移 地 址 控制 内 核 和 用 户 程序 占据 的 地 址 空 
间 。 在 Linux 系 统 上 ， 约 定 内 核 占用 3GB~4GB 的 地 址 空间 ， 而 应 用 程序 使 用 
0~3GB 。 


那么 内 核 是 如 何 将 目 己 的 地 址 空间 限制 在 3GB 以 上 的 呢 ? 如 同 普 通 应 
用 程序 一 样 ， 内 核 符号 的 地 址 也 是 编译 时 链接 句 分 配 的 ， 查 看 链接 内 核 时 
链接 器 使 用 的 链接 如 脚本 : 


1Linux-3.7.4/arch/x86/kernel/vmlLinux.1lads.S: 


SECTIONS 
{ 
#ifdef CONFIG X86 32 
. = LOAD OFFSET + LOAD PHYSICAL ADDR; 
phys_ startup 32 = startup 32 - LOAD OFFSET; 
#else 


} 


其 中 LOAD_PHYSICAL_ADDR 是 假定 的 内 核 在 物理 内 存 中 的 实际 加 载 
位 置 ， 而 LOAD_OFFSET 就 是 人 为 让 内 核 在 线形 地 址 空间 中 的 偏 移 ， 其 定 
义 如 下 : 


linux-3.7.4/arch/x86/kernel/vmlinux.1ds.s: 


#define LOAD OFFSET PAGE OFFSET 
linux-3.7.4/arch/x86/include/asm/page 32 types.h: 
#define PAGE OFFSET _AC (CONFIG PAGE OFFSET, UL) 
linux-3.7.4/.config: 


CONFIG PAGE OFFSET=0xC0000000 


可 见 对 于 IA32 来 说 ， 这 个 偏 移 默 认 是 3GB。 


我 们 看 到 ， 如 果 不 增加 偏 移 LOAD_OFFSET， 内 核 中 指令 的 起 始 地 址 
就 是 LOAD_PHYSICAL_ADDR。 如 果 内 核 在 内 存 中 也 是 实际 加 载 到 了 
LOAD_PHYSICAL_ADDR， 那 么 指令 或 者 数据 的 地 址 就 是 物理 地 址 。 


而 在 平坦 内 存 模型 下 ， 在 未 开局 分 页 时 ，CPU 送 给 MMU 的 逻辑 地 址 经 
过 MMU 转 换 后 ， 偏 移 地 址 将 原封 不 动 的 作为 物理 地 址 送 到 总 线 上 : 


物理 地 址 = 偏 移 地 址 + 段 基 址 (0) = 侦 移 地 址 


显然 ， 这 要 求 CPU 送 出 的 偏 移 地 址 就 是 物理 地 址 。 但 事实 上 ， 内 核 中 
指令 和 数据 的 地 址 在 链接 时 都 增加 了 偏 黎 LOAD_OFFSET。 因 此 ， 在 没有 
开启 分 页 机 制 前 ， 如 果 使 用 内 核 中 的 符号 ， 必 须要 减 去 偏 移 
LOAD_OFFSET。 因 此 ， 内 核 中 定义 了 宏 pa， 其 目的 就 是 将 逻辑 地 址 去 除 人 
为 安排 的 3GB 偏 移 。 宏 pa 的 定义 如 下 : 


linux-3.7.4/arch/x86/kernel/head 32.8: 
#define Pa(X) ((X) - __PAGE OFFSET) 
如 在 head_32.S 中 ， 寻 址 boot_gdt_descr、initial_page_table 等 符号 时 ， 


为 尚未 开局 分 页 ， 所 以 均 使 用 了 宏 pa。 


而 在 CPU 开 局 分 页 机 制 后 ， 通 过 页 表 的 映射 ， 这 个 3GB 的 偏 移 将 被 消 
除 。 因 此 ， 在 第 二 次 加 载 gdtr， 引 用 符号 early_gdt_descr 时 ， 驶 不 再 需要 进 
行 任何 手动 的 转换 了 。 


2. 创 建 内 核 页 表 


前 面 我 们 讨论 了 内 核 为 地 址 转换 过 程 中 MMU 的 分 段 单 元 准备 GDT 的 过 
程 。 这 里 我 们 来 讨论 内 核 为 MMU 中 人 负责 第 二 阶段 的 地 址 转换 的 分 页 单元 准 
备 的 页 表 。 


如 果 操 作 系 统 永远 在 内 核 空间 运行 ， 那么 页 表 只 需要 覆盖 内 核 空 间 束 
可 以 了 。 但 是 ， 最 终 操 作 系统 一 定 是 要 运行 进程 的 ， 对 于 一 个 进程 来 说 ， 
它 大 部 分 时 间 运 行 在 用 户 空间 ， 但 是 有 时 也 要 在 内 核 空间 运行 ， 因 此 进程 
访问 的 空间 是 整个 线形 地 址 空间 ， 包 括 用 户 空间 和 内 核 空间 。 


虽然 进程 的 用 户 空间 “ 岁 岁 年 年 人 不 同 ?， 但 是 内 核 空间 却 是 “年 年 岁 岁 
花 相 似 ”。 操 作 系统 只 有 一 个 内 核 ， 所 以 理论 上 ， 进 程 的 页 表 只 映射 用 户 空 
间 就 可 以 了 ， 进 程 运行 在 用 户 空 间 时 ， 使 用 这 个 页 表 ， 而 当 进 程 切入 内 核 
空间 时 ，CR3 寄 存 器 指向 内 核 页 表 。 但 是 ， 看 似 只 是 一 个 寄存 器 的 装载 动 
作 ， 其 背后 的 代价 却 是 非常 高 昂 的 。 因 为 地 址 空间 的 切换 ， 会 导致 TLB 被 
清空 ，TLB 中 缓存 的 是 虚拟 地 址 到 物理 地 址 的 映射 ， 它 可 以 大 大 提高 虚拟 
地 址 到 物理 地 址 的 转换 速度 。 而 且 ， 进 程 在 用 户 空间 和 内 核 空间 的 切换 还 
是 比较 频繁 的 ， 比 如 ， 一 个 系统 调用 就 会 导致 进程 切换 到 内 核 空间 。 因 
此 ，Linux 操 作 系 统 采用 了 这 样 一 个 见 余 策 略 ， 在 每 个 进程 的 页 表 中 都 包含 
了 相同 的 内 核 空 间 映 射 部 分 。 这 样 ， 当 进程 在 用 户 空间 和 内 核 空间 切换 
时 ， 不 必 重 新 狼 载 CR3 寄 存 器 。 


在 内 核 刚 刚 开始 初始 化 时 ， 内 存 尚 未 进行 完全 的 初始 化 ， 所 以 内 核 将 
页 表 的 初始 化 分 成 两 个 阶段 进行 。 在 开局 页 式 映 射 前 ， 内 核 还 只 能 使 用 汇 
编 语言 。 在 准备 基本 的 运行 环境 中 ， 你 原意 使 用 汇编 语言 考虑 各 种 负责 的 
情况 吗 ? 当然 不 愿意 了 ， 我 们 当然 希望 尽早 地 准备 好 可 以 使 用 C 语 言 的 环 
境 。 因 此 ， 这 时 内 核 仅 建 立 一 个 小 的 够 用 的 临时 页 目录 和 页 表 。 在 页 式 映 
味 开 局 后 ， 内 核 束 可 以 毫 无 顾忌 地 使 用 C 语 言 编写 的 代码 了 ， 于 是 内 核 进行 


内 存 的 初始 化 。 在 内 存 子 系统 初始 化 完全 完成 后 ， 内 核 再 调用 C 语 言 贸 数 建 
立 完整 的 页 表 。 


通常 ， 内 核 创建 的 这 个 页 目录 和 页 表 也 被 称 为 主 内 核 页 目录 和 页 表 ， 
它们 也 作为 进程 的 页 目录 和 页 表 的 模板 。 每 当 进程 创建 页 表 时 ， 其 将 从 主 
内 核 创建 的 这 部 分 页 目录 和 页 表 复 制 页 目录 项 和 页 表 项 。 当 内 核 的 内 存 映 
味 发 生变 化 时 ， 内 核 将 更 新 主 内 核 页 目录 和 页 表 ， 同 时 ， 也 同步 进程 的 页 
目录 和 页 表 中 映射 内 核 的 页 目录 项 和 页 表 项 。 而 对 于 页 表 的 用 户 空间 部 
分 ， 因 为 与 具体 进程 密切 相关 ， 因 此 由 具体 进程 运行 时 按 需 创建 。 


在 本 小 节 中 ， 我 们 讨论 了 内 核 第 一 阶段 手工 创建 页 表 的 过 程 ， 后 面 第 
二 阶段 使 用 C 语 言 构建 页 表 的 过 程 与 此 原理 完全 相同 ， 只 不 过 高 度 自动 化 
了 ， 我 们 不 再 重复 。 


(1) 页 目录 和 页 表 的 存储 位 置 


最 初 ， 页 目录 的 位 置 存 放 在 BSS 段 中 的 变量 swapper_pg_dir 处 。 在 建立 
页 目录 表 时 ， 除 了 需要 将 页 目录 中 映射 内 核 空 间 的 部 分 映射 到 内 核 占据 的 
物理 内 存 外 ， 还 要 把 页 目 孙 中 映射 用 户 空间 的 最 初 部 分 也 映射 到 内 核 占据 
的 物理 内 存 。 内 核 为 什么 要 这 么 做 呢 ? 这 是 x86 架 构 明 确 要 求 的 ， 在 Intel 的 
手册 中 明确 规定 了 CPU 切换 到 保护 模式 ， 并 开局 页 式 映 射 时 的 一 个 要 求 ， 
具体 如 下 |: 


9.9.1 Switching to Protected Mode 


6. If paging is enabled, the code for the MOV CRO instruction 
and the JMP or CALL instruction must come from a page that 
is identity mapped (that is, the linear address before the 
jump is the same as the physical address after paging and 
protected mode is enabled). The target instruction for the 
JMP or CALL instruction does not need to be identity mapped. 


准确 的 原因 需要 问 Intel CPU 的 设计 者 了 ， 但 是 原因 之 一 是 : 在 CPU 设 
置 了 寄存 右 CR0 开 局 分 页 机 制 后 ， 显 然 所 有 地 址 都 应 该 使 用 虚拟 地 址 ， 而 不 
再 使 用 物理 地 址 ， 因 此 内 核 将 使 用 一 条 长 跳 转 指 令 ， 使 EIP 重 新 饭 载 下 一 条 
指令 的 虚拟 地 址 。 但 是 ， 在 寻 址 这 条 长 跳 转 指令 本 喘 时 ， 依 然 使 用 的 古物 
理 地 址 。 显 然 ， 要 确保 经 过 页 面 映射 后 ， 这 条 指令 依然 可 以 正确 映 冉 到 其 
所 在 的 物理 内 存 ， 因 此 页 目录 中 映射 用 户 空 间 的 最 初 部 分 ， 即 没有 3GB 偏 
移 的 部 分 ， 也 映射 到 内 核 占 据 的 物理 内 存 。 也 就 是 说 ， 物 理 地 址 经 过 页 面 
映射 ， 依 然 可 以 映射 到 正确 的 物理 地 址 。 这 就 是 Intel 手 册 中 表达 的 所 谓 的 恒 


等 映射 (identity map) 


曾经 一 段 时 间 ， 这 种 机 制 工作 得 很 好 ， 也 没有 出 现 过 什么 问题 。 但 是 
后 来 ， 在 某 些 32 位 的 x86 处 理 器 上 将 swapper_pg_dir 作 为 页 表 激 活 其 他 CPU 
(secondary CPU) 时 出 现 了 一 些 bug。 引 起 这 个 bug 的 原因 就 是 恒 等 映射 。 


为 了 解决 这 个 问题 ， 内 核 引 入 了 变量 initial _page_table， 其 与 
swapper_pg_dir 一 样 ， 也 定义 在 内 核 的 BSS 段 : 


linux-3.7.4/arch/x86/kernel/head 32.S: 


/* 
* BSS section 


7 


ENTRY (initial page table) 
ll] 10247470 


ENTRY (swapper pg dir) 
ll T0242,0 


按照 x86 架 构 的 要 求 ， 在 initial_page_table 中 进行 了 恒 等 映 射 。 但 是 
initial_page_table 只 是 在 最 初 引 导 时 使 用 ， 一 旦 引导 完成 ， 内 核 将 
initial_page_table 处 的 内 核 页 表 复 制 到 swapper_ pg_dir， 但 十 只 复制 非 恒 等 映 
员 部 分 ， 然 后 将 swapper_pg_dir 淡 载 到 寄存 右 CR3。 也 束 是 说 ， 内 核 使 用 位 
置 swapper_pg_dir 处 的 页 目录 作为 最 终 的 页 目录 ,代码 如 下 : 


linux-3.7.4/arch/x86/kernel/setup.c: 


void init setup arch(char **cmdline PP) 


clone pgd range (swapper pg dir + KERNEL PGD BOUNDARY， 
initial page table + KERNEL PGD BOUNDARY, 
KERNEL PGD PTRS); 


load cr3(swapper pg _ dir),; 


后 续 激 活 其 他 CPU 时 ， 内 核 也 使 用 这 个 去 除了 恒 等 映 射 的 
swapper_pg_dir 作 为 页 目录 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/kernel/smpboot.c: 


/* 


* Activate a secondary processor. 
sh 
notrace static void cpuinit start secondary (void *unused) 


{ 


/* switch away from the initial page table */ 
load cr3(swapper pg dir); 


除了 要 保存 页 目录 外 ， 内 核 中 也 要 分 配 存储 页 表 的 地 方 。 内 核 会 将 页 
表 存 储 在 BSS 后 面 的 brk 段 中 从 标号 _ brk_base 开 始 的 地 方 。_brk_base 在 内 
核 链 接 肢 本 vmlinux.lds.S 中 定义 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/kernel/vmlinux.1ds.s: 


SECTIONS 


{ 


. = ALIGN (PAGE SIZE); 


.brk : AT(ADDR(.brk) - LOAD OFFSET) { 
_brk base = .; 
. += 64 * 1024; /* 64k alignment slop space */ 
*(.brk reservation) /* areas brk users have reserved */ 
_ Bek Limlt .a wf 


内 核 中 的 brk 概 念 与 普通 程序 中 的 brk 的 概念 基本 相同 ， 都 表示 动态 内 存 
分 配 的 内 存 区 域 。 


(2) 建立 页 目录 和 页 表 


在 创建 页 目录 和 页 表 时 ， 第 一 步 需 要 找到 页 目录 和 页 表 所 在 的 位 置 ， 
然后 按照 IA32 架 构 的 页 目录 项 和 页 表 项 的 格式 约定 ， 逐 项 填充 各 个 表 项 。 
IA32 架 构 的 页 目 如 项 和 页 表 项 的 格式 如 图 5-17 所 示 。 


Page-Directory Entry(4KB page) 


| Pp 
Address of page table ignored gilAlc 
n D 


Page-Table Entry(4KB page) 


P P|P|UIR 
Address of 4KB page frame ignored| G | A | | | 
i Bi |S | 


图 5-17 页 目录 项 和 页 表 项 的 格式 


内 核 初始 化 时 创建 页 目录 项 和 页 表 项 的 代码 片段 如 下 : 


linux-3.7.4/arch/x86/kernel/head 32.S: 


01 page pde offset = (PAGE OFFSET >> 20); 

02 

03 movl S$pa(l_ brk base), $%edi 

04 movl1 S$palinitial page table), gedx 

05 movl $PTE IDENT ATTR, Seax 

06 10': 

07 leal PDE IDENT ATTR(%edi),%ecx /* Create PDE entry */ 
08 movl %ecx, (%edx) /* Store identity PDE entry */ 
09 movl1 %ecx,page pde offset (%edx) /* Store kernel PDE entry */ 
10 addl $4,%edx 

UL movl $1024, %ecx 

2 ls 

a stosl 

工业 addl $0x1000,%eax 

15 loop 11b 

16 en 

TI movl S$pa(_end) + MAPPING BEYOND END + PTE IDENT ATTR, %ebp 
18 cmpl %ebp, Seax 


19 jb 10b 


上 述 代 码 中 包含 了 一 个 二 重 循 环 ， 代码 第 6~19 行 是 第 一 层 循环 ， 这 层 
循环 的 目的 是 填充 页 目录 项 ， 直 到 建立 的 页 表 映 射 的 地 址 可 以 覆盖 
end+MAPPING_BEYOND_END。 其 中 符号 _end 在 链接 脚本 vmlinux.lds.S 中 


定义 ， 标 识 内 核 映 像 的 来 尾 。 这 里 多 映射 了 MAPPING_BEYOND_END 目 的 
是 为 后 面 第 二 阶段 要 建立 完整 的 页 表 准 备 空间 。 代 码 第 12~15 行 是 第 二 层 循 
环 ， 这 层 循 环 每 次 循环 1024 次 ， 目 的 是 填充 一 个 页 表 中 的 1024 个 页 表 项 。 


填充 页 目录 项 


先 来 看 创建 页 目录 项 的 第 一 层 循环 。 第 4 行 代码 将 页 目录 所 在 的 位 置 
initial_page_table 存 入 寄存 器 edx。 第 3 行 和 第 7 行 代码 共同 创建 了 第 一 个 页 目 
录 项 的 内 容 ， 将 其 保存 到 寄存 器 ecx。 根 据 第 3 行 代码 可 见 ， 第 一 个 页 表 位 
于 符号 _brk_base 处 ， 这 个 符号 也 在 链接 脚本 vmlinux.lds.S 中 定义 ， 基 本 上 
相当 于 普通 进程 的 Program break 处 ， 也 就 是 堆 开 始 的 地 方 。 


在 确定 了 页 目录 项 所 在 的 位 置 ， 并 且 也 准备 好 了 页 目录 项 的 内 容 后 ， 
第 8 行 代码 将 准备 好 的 页 目录 项 的 内 容 填充 到 页 目录 项 所 在 的 位 置 。 


在 建立 初始 引导 使 用 的 页 目录 表 initial_page_table 时 ， 除 了 需要 将 页 目 
录 中 映射 内 核 空间 的 部 分 映 冉 到 内 核 占据 的 物理 内 存 外 ， 还 要 把 页 目 中 映 
喘 用 户 空间 的 最 初 部 分 也 映射 到 内 核 占 据 的 物理 内 存 ， 也 束 是 前 面谈 到 的 
恒 等 映 射 ， 这 里 第 9 行 代 码 吏 是 做 这 件 事 的 。 


填充 页 表 项 


第 二 层 循 环 完 成 页 表 项 的 填充 。 和 驳 来 看 第 13 行 处 的 汇编 指令 stos1， 该 指 
令 将 寄存 器 eax 中 的 值 存 储 到 寄存 器 edi 指 示 的 内 存 处 ， 然 后 将 寄存 器 edi 中 的 
值 增加 4 于 条。 显然 ， 寄 存 右 edi 中 保存 的 是 页 表 项 所 在 的 位 置 ，eax 中 保存 
的 是 页 表 项 的 内 容 。 


根据 第 3 行 代码 可 见 ， 寄 存 器 edi 的 初 值 被 设置 为 _brk_base， 世 就 是 
说 ， 第 1 个 页 表 在 符号 _brk_ base 处 。 寄 存 器 eax 的 初 值 在 第 5 行 代码 中 设置 
为 PTE IDENT_ATTR.: 


linux-3.7.4/arch/x86/include/asm/pgtable types .hi: 


#define PTE IDENT ATTR 0X003 /* PRESENT+RW */ 


因为 PTE_IDENT_ATTR 的 高 20 位 为 0， 所 以 寄存 器 eax 的 高 20 位 也 为 0。 
也 就 是 说 ， 第 一 个 页 表 项 映射 的 内 存 页 面 是 从 内 存 0 开始 的 一 个 页 面 。 


因此 ， 第 二 层 循环 从 _brk base 处 填充 页 表 项 ， 第 一 个 页 表 项 获 凋 了 从 
内 存 0 开始 的 一 个 页 面 ， 以 后 每 次 循环 后 将 eax 指 回 的 物理 地 址 增加 4KB ， 见 
第 14 行 代码 ， 即 指向 下 一 个 物理 内 存 页 面 ， 依 次 类 推 。 第 11 行 代码 设置 循 
环 的 次 数 为 1024， 所 以 第 二 层 循环 循环 1024 次 ， 将 第 一 个 页 表 全 部 填充 。 
最 终 ， 第 一 个 页 表 映 射 了 从 0 开始 的 4MB 内 存 空间 。 


第 二 层 循环 结束 后 ， 代 码 将 再 次 进入 第 一 层 循环 ， 重 新 开始 新 一 轮 大 
循环 。 我 们 看 一 下 新 一 轮 循环 页 目录 项 和 页 表 分 别 所 在 的 位 置 。 第 10 行 代 
码 将 寄存 器 edx 增 加 了 4 字 节 ， 即 指向 下 一 个 页 目录 项 。 而 在 第 二 层 循环 结 
束 后 ， 寄 存 器 edi 恰 好 指向 第 一 个 页 表 后 的 末尾 ， 这 里 也 就 是 即将 开始 的 第 


二 个 页 表 的 起 始 位 置 。 然 后 ， 内 核 开 局 填充 第 二 个 页 目录 项 ， 然 后 进行 第 
二 个 页 表 的 过 程 ...... 以 此 类 推 ， 当 建立 的 页 表 已 经 可 以 映射 到 物理 地 址 
_end+MAPPING _ BEYOND_END 时 ， 即 完成 了 初始 页 表 的 建立 。 


最 终 ， 内 核 建立 的 页 目录 以 及 页 表 如 图 5-18 所 示 。 
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图 5-18 内 核 初始 页 表示 意图 


(3) 启动 分 页 机 制 


页 目录 和 页 表 准 备 好 后 ， 内 核 设 置 寄存 胡 CR3 指 癌 页 目录 ， 设 置 寄存 右 
CR0 中 的 PG 位 ， 开 局 页 式 映 射 ， 代 码 片段 如 下 : 


linux-3.7.4/arch/x86/kernel/head 32.S: 


mov1 S$pal(linitial page table), %eax 
moOvV1 %Seax,%gcr3 /* set the page table pointer.. */ 


mOV] %cr0, Seax 

orl $X86 CRO PG, %eax 

movl] Seax,gScr0 /* ..and set paging (PG) bit */ 

ljmp $ BOOT CS,$1f /* Clear prefetch and normalize geip */ 


[1] 来 源 : Intel 64 and IA-32 Architectures Software Developer's Manual, 


Volume 3A: System Programming Guide,Part 1.January 2011。 


5.3.2 ”初始 化 进程 0 


POSIX 标 准 规定 ， 符 合 POSIX 标 准 的 操作 系统 采用 复制 的 方式 创建 进 
程 ， 但 是 内 核 总 得 想 办 法 创建 第 一 个 原始 的 进程 ， 否 则 其 他 进程 复制 谁 
呢 ? 因此 ， 内 核 静 态 的 创建 了 一 个 原始 进程 ， 因 为 这 个 进程 是 内 核 的 第 一 
个 进程 ，Linux 为 其 分 配 的 进程 号 为 0， 所 以 也 被 称 为 进程 0。 进程 0 不 仅 作 
为 一 个 模板 ， 在 没有 其 他 就 绪 任 务 时 进程 0 将 投入 运行 ， 所 以 其 又 称 为 idle 
进程 。 下 面 我 们 束 看 看 内 核 是 如 何 为 进程 0 分 配 任 务 结构 和 内 核 栈 这 两 个 关 
键 数据 结构 的 。 


1. 创 建 任务 结构 


进程 0 的 任务 结构 的 定义 如 下 : 


linux dry sd/init/init taskyes 
struct task struct init task = INIT TASK(init task); 
linz=37:4/include/linux/init task:.h: 


#define INIT TASK(tsk) \ 


{ \ 
.state = 0， 
.Stack = &init thread info, NY 
.Usage = ATOMIC INIT(2), 


其 中 变量 init_task 所 在 的 位 置 (在 内 核 的 数据 段 中 ) 就 是 进程 0 的 任务 
结构 。 


当前 进程 的 任务 结构 是 一 个 频繁 使 用 的 变量 ， 为 了 方便 获取 它 ， 内 核 
中 专门 定义 了 一 个 宏 current。 这 个 获取 方法 几经 修改 ， 现 在 的 方式 是 定义 了 
一 个 变量 current_task 指 向 当前 进程 的 任务 结构 。 在 内 核 初 始 化 时 ， 内 核 将 
这 个 变量 设置 为 指向 init_task， 换 句 话 说， 当前 进程 是 进程 0， 代 码 如 下 : 


linux-3.7.4/arch/x86/kernel/cpu/common.c 


DEFINE PER CPU(struct task struct *, current task) = &init task; 


读者 不 必 关 心 所 谓 的 PER_CPU， 这 是 内 核 为 了 优化 而 定义 的 。 为 了 在 
SMP 情 况 下 减少 锁 的 使 用 ， 内 核 中 为 每 笑 CPU 都 定义 了 一 个 current_task 。 


安 current 就 是 通过 读 取 current_task 来 获取 当前 进程 的 任务 结构 ， 定 义 如 
下 : 


linux-3.7.4/arch/x86/include/asm/current.h: 
#define current get current () 


static _ always inline struct task struct *get current (void) 


{ 
} 


return this cpu read stable(current task); 


接 下 来 在 内 核 创 建 第 一 个 真正 意义 上 的 进程 (进程 1) 上 时， 内核 将 从 
current 指 向 的 进程 进行 复制 ， 而 此 时 这 个 current 恰 恰 指 向 进程 0 的 任务 结 
构 。 


2. 进 程 0 的 内 核 栈 


进程 0 不 会 切换 到 用 户 空间 ， 所 以 无 需 用 户 空 间 的 栈 ， 只 需 为 其 安排 好 
内 核 空间 的 栈 即 可 。 进 程 内 核 栈 的 数据 结构 抽象 如 下 : 


linux-3.7.4/include/linux/sched.h: 
union thread union { 


struct thread info thread info; 
unsigned long stack[THREAD SIZE/sizeof (long)]; 


这 个 抽象 中 的 数组 stack 就 是 内 核 栈 ， 对 于 IA32， 宏 THREAD_SIZE 定 义 
为 8KB， 可 见 内 核 为 进程 内 核 栈 分 配 的 大 小 为 两 个 页 面 。 那 么 为 什么 进程 
的 内 核 栈 与 另外 一 个 结构 体 thread_info 定 义 在 一 起 呢 ? 我 们 后 面 再 讨论 这 个 
问题 ， 下 面 先 来 具体 看 一 下 进程 0 的 内 核 栈 : 


LLU 3 TA/NLt/ Lili ta 


union thread union init thread union init task data = 
{ INIT THREAD INFO(init task) }; 


其 中 ， 变 量 init_thread_union 就 是 进程 0 的 内 核 栈 所 在 的 位 置 ， 这 个 变量 
也 是 在 内 核 的 数据 段 中 ， 当 然 其 栈 底 是 在 init_thread_union+THREAD_SIZE 


处 了 ， 如 图 5-19 所 示 。 


init thread union _ ,， 


+ THREAD SIZE 所 esp 


二 


THREAD SIZE stack[THREAD SIZE/sizeof(long)] 


thread info 


init thread union 一 一 


图 5-19 进程 0 的 内 核 栈 


在 内 核 初始 化 时 ， 设 定 了 栈 指针 esp 指 问 
init_thread_union+THREAD_SIZE， 代 码 如 下 : 


linux-3.7.4/arch/x86/kernel/head 32.5S: 


ENTRY (startup 32) 
movl1l palstack start),S%ecx 


leal - PAGE OFFSET(%ecx),%esp 


ENTRY (stack start) 
.long init thread union+THREAD SIZE 


为 此 时 尚未 开启 分 页 机 制 ， 而 符号 stack_start 以 及 init_thread_union 均 
使 用 的 是 加 了 偏 移 (0xc0000000) 的 虚拟 地 址 ， 所 以 这 里 都 要 去 掉 这 个 偏 
移 。 而 在 开局 页 式 映射 后 ， 把 这 个 偏 移 又 加 了 回来 ， 如 下 面 代码 中 使 用 黑 
体 标识 的 部 分 : 


linux-3.7.4/arch/x86/kernel/head 32.S: 
ENTRY (startup 32) 
movl1 %cr0,%Seax 
orl $X86 CRO PG,%eax 
moOoVvl1 %eax, Scr0 /* ..and set paging (PG) bit */ 


ljmp $ BOOT CS,$1f /* Clear prefetch and normalize %eip */ 


/* Shift the stack pointer to a Virtual address */ 
addl $ PAGE OFFSET, %esp 


最 后 ， 为 了 在 进程 切换 时 可 以 找到 进程 0 的 内 核 栈 ， 还 要 将 其 保存 在 进 
程 0 的 任务 结构 的 结构 体 thread_struct 的 对 象 thread 中 ， 代 码 如 下 : 


Linux-3s7 4/include/lTinux/init: tagk hl: 


#define INIT TASK (tsk) \ 
{ \ 
.thread = INIT THREAD, \ 


} 


linux-3.7.4/arch/x86/include/asm/processor.h: 


#define INIT THREAD { \ 
.Sp0 s Slizeof (init stack) + (long)t&init stack, \ 


} 
linux-3.7.4/arch/x86/include/asm/thread info.h: 


#define init stack (init thread union.stack) 


结构 体 thread_struct 中 的 sp0 束 是 记录 进程 内 核 栈 的 栈 指针 。 


3. 宏 current 与 进程 内 核 栈 


这 一 小 节 我 们 来 回答 为 什么 进程 的 内 核 栈 与 男 外 一 个 结构 体 thread_info 
定义 在 一 起 的 问题 。 


在 2.4 版 本 以 前 ， 内 核 直接 将 任务 结构 舱 入 在 堆栈 的 最 下 方 。 但 是 鉴 
任务 结构 也 占据 不 小 的 空间 ， 而 且 要 把 任务 结构 放 在 栈 后 ， 还 需要 把 任务 
结构 复制 到 栈 中 。 因 此 ， 在 2.6 版 本 时 ， 内 核 设 计 了 结构 体 thread_info， 取 而 
代 之 的 是 thread_info 放 在 了 栈 克 。 通 过 对 寄存 船 esp 进行 对 齐 运 算 ， 即 可 方 
便 地 找到 当前 进程 的 thread_info: 


linux-3.7.4/arch/x86/include/asm/thread info.h: 
register unsigned long current stack pointer asm("esp") _ used; 
static inline struct thread info *current thread info(void) 
{ 
return (struct thread info *) 


(current stack pointer & ~(THREAD SIZE - 1)); 


} 


而 thread_info 中 有 一 个 指针 指 回 进程 的 任务 结构 ， 因 此 获取 当前 进程 的 
任务 结构 的 方法 如 下 : 


linux-3.7.4/include/asm-generic/current.h: 


#define get current() (current thread info'()->task) 
#define current get current () 


但 是 ， 内 核 开发 者 还 是 认为 计算 thread_info 位 置 时 间 过 长 ， 于 是 采用 了 
以 空间 换 时 间 的 办 法 ， 从 2.6.22 版 本 开始 ， 内 核 在 内 存 中 定义 了 一 个 变量 
current_task 记 录 当 前 进程 的 任务 结构 。 内 核 不 再 通过 计算 ， 而 是 直接 通过 
一 条 访 存 指令 来 设置 或 者 读 取 当前 进程 的 任务 结构 。 


我 们 在 前 面 看 到 ， 在 内 核 初始 化 时 ，current_task 指 同 进程 0 的 任务 结构 
init_task。 以 后 每 次 切换 进程 时 ， 调 度 函 数 设 置 current_task 指 向 下 一 个 投入 
运行 的 进程 的 任务 结构 : 


linux-3.7.4/arch/x86/Kkernel/process 32.c: 


__ notrace funcgraph struct task struct * 
.witeh to(lstruet task struet “prev Pp Strueb taek struct 
*next p) 


this cpu write(current task, next p); 


5.3.3 ”创建 进程 1 


在 内 核 初始 化 的 最 后 ， 将 调用 kerel _ thread 创建 进程 1， 代 码 如 下 : 


linux=3.7.4/init/malin,ce; 


static noinline void init refok rest init (void) 


{ 


J NULL, CLONE FS | CLONE SIGHAND); 
} 
linux-3.7.4/kernel/fork.c 
pid t kernel thread(int (*fn) (void *), void *arg, ...) 


{ 


return do fork (flags |CLONE VM|CLONE UNTRACED, 
(unsigned long)fn, NULL, (unsigned long)arg, NULL, NULL); 


根据 kernel_thread 代 码 可 见 ， 进 程 1 是 通过 复制 进程 0 而 来 的 。 在 复制 了 
进程 后 ， 将 执行 kernel_init， 相 关 代 码 如 下 : 


工人 三 /二 


static int ref kernel init(void *unused) 


{ 


if (!run init process (ramdisk execute command)) 


} 


static int run init process(const char *init filename) 


argv init[0] = init filename; 
return kernel] _execve (init filename, argv init, envp init); 


} 


linux-3.7.4/fs/exec.c: 


int kernel execve(const char *filename, ...) 


{ 


ret = do_execve (fiLename，.，:)7 


根据 代码 可 见 ， 我 们 已 经 看 清楚 了 ， 第 一 个 进程 的 创建 过 程 与 我 们 在 
用 户 空间 创建 一 个 进程 并 无 本 质 区 别 ， 就 是 我 们 惯用 的 套路 : fork+exec。 


创建 进程 1 后 ， 内 核 调用 函数 sechedule 让 进程 1 投入 运行 。 在 讨论 进程 1 
的 投入 运行 前 ， 我 们 先 来 了 解 一 下 内 核 的 基本 调度 原理 ， 如 图 5-20 所 示 。 
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图 5-20 ”内核 调度 机 制 示意 图 


内 核 采用 模块 化 的 方法 ， 将 任务 分 成 四 类 ， 优 先 级 从 高 到 低 分 别 是 停 
止 类 (stop_sched_class) 、 实 时 类 (rt_sched_class) 、 公 平 类 
(fair_sched_class) 和 空闲 类 (idle_sched_class) 。 从 名 字 我 们 就 可 以 判断 
出 了 这 几 个 类 中 归属 的 任务 类 型 了 。 实 时 类 中 记录 的 是 实时 任务 ， 一 般 的 
任务 都 归 类 在 公平 类 中 ， 而 停止 类 和 空闲 类 中 记录 的 是 两 个 特殊 的 任务 。 


在 没有 其 他 任务 就 绪 时 ，CPU 将 运行 空腹 类 中 的 任务 ， 该 任务 将 CPU 
置 于 停机 状态 ， 直 到 有 中 断 将 其 唤醒 。 而 停止 类 中 的 任务 是 用 于 负载 均衡 
或 者 进行 CPU 热 插 拔 时 使 用 的 任务 ， 顾 名 思 义 ， 其 目的 是 为 了 停止 正在 运 
行 的 CPU， 以 进行 任务 迁移 或 者 插 拔 CPU。 每 个 CPU 分 别 只 有 一 个 停止 任务 
和 至 朵 任务 。 


实时 类 和 公平 类 分 别 有 一 个 就 绪 队 列 rt_rq 和 cfs_rq， 维 护 着 可 以 投入 运 
行 的 任务 。 每 个 束 绪 队列 有 目 己 的 排队 算法 ， 比 如 公平 类 采用 红 黑 树 对 整 
绪 的 任务 进行 排队 。 


这 几 个 类 组 成 了 一 个 链表 ， 其 中 最 高 优先 级 的 停止 类 作为 表 头 。 每 个 
CPU 有 一 个 就 绪 队 列 (run queue) ， 通 过 该 队列 ， 可 以 访问 实时 队列 、 公 
平 队列 以 及 停止 任务 和 空闲 任务 。 


每 当 调度 发 生 时 ， 调 度 函 数 schedule 调 用 函数 pick_next_task 按 照 优 先 级 
依次 遇 历 各 个 类 ， 找 出 下 一 个 投入 运行 的 任务 ， 代 人 码 如 下 : 


linux-3.7.4/kernel/sched/core.c: 


static inline struct task struct *pick next task(struct rq *rq) 
const struct sched class *class; 
struct task struct *p; 


if (likely(rq->nr running == rq->cfs.h nr running)) { 
p = fair sched class.pick next task (rq); 
if (likely(p)) 
return p; 


} 


for each class(class) { 
p = class->pick next task (rq); 
EE ( 扩 
return p; 


和 完 看 函数 pick_next_task 中 后 面 的 for 循 环 ， 显 然 这 是 在 遍历 调度 类 。 
pick_next_task 从 优先 级 最 高 的 停止 类 开始 碍 找 ， 每 个 类 提供 了 各 自 的 函数 
pick_next_task， 从 就 绪 队 列 中 选择 需要 投入 运行 的 任务 。 


除非 用 在 特定 的 领域 ， 人 否则 大 部 分 任务 应 该 属于 公平 类 ， 所 以 内 核 开 
发 人 员 对 调度 算法 进行 了 一 个 小 小 的 优化 : 如 果 目 前 系统 就 绪 的 任务 都 属 
于 公平 类 ， 则 直接 从 公平 类 中 挑 迁 下 一 个 任务 。 这 就 古 for 循 环 前 面 的 代码 
片段 的 作用 。 


那么 进程 0 和 进程 1 分 别 都 征 属于 哪个 调度 类 昵 ? 看 下 面 的 代码 : 


linux-3.7.4/kernel/sched/core.c: 


void _init sched init (void) 


{ 


current->sched class = &fair sched class; 


在 内 核 初 始 化 时 ， 在 调度 相关 的 初始 化 函数 sched_init 中 ， 进 程 0 的 调度 
类 被 设置 为 公平 类 ， 因 此 ， 在 从 进程 0 复制 后 ， 进 程 1 也 是 公平 类 。 而 在 复 
制 完成 进程 1 后 ， 内 核 将 进程 0 的 调度 类 设置 为 空 亲 类， 代码 如 下 : 


Tn 74/4nLt/maLn es 


static noinline void init refok rest init{void) 


{ 


kernel thread(kernel init, NULL, CLONE FS | CLONE SIGHAND); 


init idle bootup task (current); 


linux-3.7.4/kernel/sched/core.c: 


void _cpuinit init idle bootup task(struct task struct *idle) 


{ 
} 


idle->sched class = &idle sched class; 


在 调用 init_idle_bootup_task 设 置 了 进程 0 的 调度 类 后 ， 内 核 调 用 函数 
schedule_preempt_disabled 进 行 调度 ， 代 码 如 下 : 


linux-3.7.4/init/main.c: 


static noinline void init refok rest init (void) 


{ 
kernel thread(kernel init, NULL, CLONE FS | CLONE SIGHAND) ; 


init idle bootup task (current); 

schedule preempt disabled(); 

/* Call into cpu idle with preempt disabled */ 
cpu idle(); 


作为 公平 类 中 的 进程 1 显然 要 排 在 属于 空闲 类 的 进程 0 的 前 面 ， 因 此 ， 
在 这 次 调度 后 ， 进 程 1 将 被 调度 函数 选中 ， 作 为 下 一 个 投入 运行 的 任务 。 而 

当 系 统 没 有 其 他 就 绪 任 务 时 ， 将 返回 到 函数 schedule_preempt_disabled 中 ， 
继续 执行 进入 函数 cpu_idle。cpu_idle 束 是 一 个 无 限 的 循环 ， 循 环 主体 就 是 
CPU 停机 ， 等 待 下 一 次 被 唤醒 执行 任务 。 可 见 ， 进 程 0 的 主体 最 后 就 退化 为 
一 个 无 限 的 while 循 环 。 


5.4 ”进程 加 我 


根据 POSIX 标 准 的 规定 ， 操 作 系统 创建 一 个 新 进程 的 方式 是 进程 调用 
操作 系统 的 fork 服 务 ， 复 制 当 前 进程 作为 一 个 新 的 子 进程 ， 然 后 子 进程 使 用 
操作 系统 的 服务 exec 运 行 新 的 程序 。 前 面 ， 我 们 看 到 内 核 已 经 静态 地 创建 了 
一 个 原始 进程 ， 进 程 1 复制 这 个 原始 进程 ， 然 后 加 载 了 用 户 空 间 的 可 执行 文 
件 。 这 一 节 ， 我 们 就 来 探讨 用 户 进程 的 加 载 过 程 ， 大 致 上 整个 加 载 过 程 包 
括 如 下 几 个 步 又: 


1) 内 核 从 磁 强 加 载 可 执行 程序 ， 建 立 进程 地 址 空间 ; 


2) 如 果 可 执行 程序 是 动态 链接 的 ， 那 么 加 载 动 态 链接 器 ， 并 将 控制 权 


转交 到 动态 链接 内; 


3) 动态 链接 郁 重 定位 目 身 ; 
4) 动态 链接 右 加 载 动态 库 到 进程 地 址 空间 ; 
5) 动态 链接 器 重 定位 动态 库 、 可 执行 程序 ， 然 后 跳 转 到 可 执行 程序 的 


入 口 处 继续 执行 。 


在 本 市 中 ， 我 们 使 用 下 面 的 例子 探讨 用 户 进 程 的 加 载 。 
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foo02 func(); 


hello.c: 
#include <stdlib.h> 


extern int fool; 
int a[2048]; 
int dummy = 10; 


void main ( ) 


{ 


char *m = malloc(1024) ; 
上 Oo 三 57 


下 总 下 EUie(): 
while (1) slLeep(1000) :; 


我 们 分 别 将 foo1.c 和 foo2.c 编 译 为 动态 库 libf1.so 和 1libf2.so， 将 hello.c 编 译 
为 一 个 可 执行 程序 ， 命 令 如 下 : 


root@baisheng:~/demo# export LD LIBRARY PATH=$LD LIBRARY PATH:. 
root@baisheng:~/demo# gcc -shared -fPIC -o libf2.so foo2.c 
root@baisheng:~/demo# gcc -shared -fPIC -o libfl.so fool.c -L. -1f2 
root@baisheng:~/demo# gcc -o hello hello.c -L. -1f1 


因为 hello 要 链接 当前 目录 下 的 动态 库 ]libf1.so 和 libf2.so， 所 以 这 里 将 当 
前 目录 添加 到 了 环境 变量 LD_LIBRARY_PATH 中 ， 告 诉 链 接 器 寻找 动态 库 
时 ， 也 包括 当前 工作 目录 。 当 然 读者 也 可 将 这 个 定义 添加 到 文件 .bashrc 中 ， 
每 次 登录 shell 时 将 自动 定义 这 个 变量 ， 和 避免 每 次 都 需要 手工 进行 定义 ， 实 
现代 码 如 下 : 


/root/ .bashrc: 


export LD LIBRARY PATH=$LD LIBRARY PATH:. 


5.4.1 ”加 载 可 执行 程序 


一 个 进程 的 所 有 指令 和 数据 并 不 一 定 全 部 要 用 到 ， 比 如 某 些 处 理 错 误 
的 代码 。 某 些 错 误 可 能 根本 不 会 发 生 ， 如 果 也 将 这 些 错误 代码 加 载 进 内 
存 ， 束 是 日 白 占 据 内 存 资 源 。 而 且 对 于 某 些 特别 大 的 程序 ， 如 果 启 动 时 全 
部 加 载 进 内 存 ， 也 会 使 局 动 时 间 延 长 ， 让 用 户 难 以 外 受 。 因 此 ， 内 核 初始 
加 载 可 执行 程序 (包括 动态 库 ) 时 ， 并 不 将 指令 和 数据 真正 的 加 载 进 内 


存 ， 而 仅仅 将 指令 和 数据 的 “地 址 ”加载 进 内 存 ， 通 常 我 们 也 将 这 个 过 程 形 
象 地 称 为 上 映射。 


对 于 一 个 程序 来 说 ， 虽 然 其 可 以 寻 址 的 空间 是 整个 地 址 空间 ， 但 是 
只 是 个 范围 而 已 ， 就 比如 某 个 楼 层 的 房间 编号 可 能 是 4 位 的 ， 但 是 并 不 意味 
着 这 个 楼 层 0000~9999 号 房间 都 可 用 。 对 于 某 个 进程 而 言 ， 一 般 也 仅仅 使 用 
了 地 址 空间 的 一 部 分 。 那 么 一 个 进程 如 何 知道 目 己 使 用 了 哪些 虚拟 地 址 
呢 ? 这 个 问题 融 较 化 为 是 谁 为 进程 分 配 的 运行 时 地 址 呢 ? 没 错 ， 是 链接 大 
分 配 的 ， 那 么 当然 从 ELF 程 序 中 获取 了 “。 所 以 内 核 首先 将 磁 弄 上 ELF 文 件 的 
地 址 映 冉 进来 。 


除了 代码 段 和 数据 段 外 ， 进 程 运行 时 还 需要 创建 保存 局 部 变量 的 栈 段 
ee 
对 应 任何 具体 的 文件 ， 所 以 也 被 称 为 匿名 映射 段 anonymous map) 。 对 于 
一 个 动态 链接 的 程序 ， 还 会 依赖 其 他 动态 库 ， 在 进程 空间 中 也 需要 为 这 些 
动态 库 预 留 空间 。 


通过 上 述 的 讨论 可 见 ， 进 程 的 地 址 空间 并 不 是 铁 板 一 块 ， 而 是 根据 不 
同 的 功能 、 权 限 划 分 为 不 同 的 段 。 某 些 地 址 根本 没有 对 应 任何 有 意义 的 指 
令 或 者 数据 ， 所 以 从 程序 实现 的 角度 看 ， 内 核 并 没有 设计 一 个 数据 结构 来 
代表 整个 地 址 空间 ， 而 是 抽象 了 一 个 结构 体 vm_area_struct。 进程 空间 中 每 
个 段 对 应 一 个 vm_area_struct 的 对 象 (或 者 叫 实例 ) ， 这 些 对 象 组 成 了 “有 
效 ” 的 进程 地 址 空间 。 进 程 运 行 时 ， 首 先 需 要 将 这 个 有 效 地 址 空间 建立 起 
有 


内 核 文 持 多 种 不 同 的 文件 格式 ， 每 种 不 同 格式 的 加 载 都 实现 为 一 个 模 
块 。 比 如 ， 加 载 ELF 格 式 的 模块 是 binfmt_elf， 加 载 脚本 的 模块 是 
binfmt_script， 它 们 都 在 内 核 的 fs 目录 下 。 对 于 每 个 要 加 载 的 文件 ， 内 核 都 
读 入 其 文件 头 部 的 一 部 分 信息 ， 然 后 依次 调用 这 些 模块 提供 的 轴 数 
load_binary 根 据 文件 头 的 信息 判断 其 是 否 可 以 加 载 。 前 面 ，initramfs 中 的 init 
程序 是 使 用 shell 脚 本 写 的 ， 显 然 ， 它 是 由 内 核 中 负责 加 载 脚 本 的 模块 
binfmt_script 加 载 。 模 块 binfmt_script 中 的 函数 指针 load_binary 指 同 的 具体 函 
数 是 load_script， 代 码 如 下 : 


linux-3.7.4/fs/binfmt. script.,c: 
static 1int load script(struct linux binpem hprm: sa) 


{ 


if (bprm Sbufltol 人 || (Bprm=Sbuflil ts Wy || sw) 
return -ENOEXEC; 


for (cp = bprm->buf+2; (*cp == ' ') || (*cp == '\t'); cp++); 


file = open exec (interp); 
bprm- >file = file,; 


return search binary handler (bprm,regs); 


linux_binprm 是 内 核 设计 的 一 个 在 加 载 程序 时 ， 临 时 用 来 保存 一 些 信息 
的 结构 体 。 其 中 ，buf 中 保存 的 就 是 内 核 读 入 的 要 加 载 程序 的 头 部 。 画 数 
load_script 首 移 判 断 buf， 也 束 是 文件 的 前 两 个 字符 是 否 是 “#I”。 这 融 是 脚本 
必须 以 人 #1* 开 头 的 原因 。 


如 果 要 加 载 的 程序 是 一 个 脚本 ， 则 load_script 从 字符 “#!" 后 的 字符 串 中 
解析 出 解释 程序 的 名 字 ， 然 后 重新 组 织 bprm， 以 解释 程序 为 目标 再 次 调用 
函数 search_binary_handler， 开 始 寻 找 加 载 解释 程序 的 加 载 锅 。 而 脚本 文件 
的 名 字 将 被 当 作 解释 程序 的 参数 庄 入 栈 中 。 


对 于 initramfs 中 的 init 程 序 ， 其 是 使 用 shell 脚 本 编写 的 ， 所 以 加 载 init 的 
过 程 转变 为 加 载 解释 程序 "bin/bash" 的 过 程 ， 而 init 脚 本 则 作为 bash 程 序 的 一 


个 参数 。 


可 见 ， 脚 本 的 加 载 ， 归 根 结 抵 还 是 ELF 可 执行 程序 的 加 载 。 


ELF 文 件 “ 一 人 分 饰 二 角 ”， 既 作为 链接 过 程 的 输出 ， 也 作为 装载 过 程 的 
输入 。 在 第 2 章 中 ， 我 们 从 链接 的 角度 讨论 了 ELF 文 件 格 式 ， 当 时 我 们 看 到 
ELF 文 件 是 由 者 干 Section 组 成 的 。 而 为 了 配合 进程 的 加 载 ，ELE 文 件 中 又 引 
入 了 Segment 的 概念 ， 每 个 Segment 包 含 一 个 或 者 多 个 Section。 相 应 于 
Section 有 一 个 Section Header Table，ELF 文 件 中 也 有 一 个 Program Header 


Table 摘 述 Segment 的 信息 ， 如 图 5-21 所 示 。 


ElFHeader | 


-pm | 
-re ki 


Program Header Table 


1 

1 

1 

1 一 - 

er 
1 
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Section Header Table 


图 5-21 ELF 文 件 中 的 Segment 与 Section 


Program Header Table 中 有 多 个 不 同类 型 的 Segment， 但 是 如 采 仔 细 观 察 
图 5-21， 我 们 会 发 现 ， 两 个 类 型 为 LOAD 的 Segment 基 本 涵盖 了 整个 ELF 文 
件 ， 而 一 些 Section， 如 ".comment"、".symtab" 等 ， 包 括 Section Header 
Table， 只 是 链接 时 需要 ， 加 载 时 并 不 需要 ， 所 以 没有 包含 到 任何 Segment 
中 。 基 本 上 ， 这 两 个 类 型 为 LOAD 的 Segment， 在 映射 到 进程 地 址 空间 时 ， 
一 个 映 冉 为 代码 段 ， 一 个 映 映 为 数据 段 : 


令 代码 段 (code segment) 具有 读 和 可 执行 权限 ， 但 是 除了 保存 指令 的 
Section 外 ， 一 些 仅 具 有 只 读 属 性 的 Section， 比 如 记录 解释 絮 名 字 
的 ".interp"， 动 态 从 号 表 ".dynsym"， 以 及 重 定位 表 ".rel.dyn"、".rel.plt"， 其 
至 是 ELF Header、Program Header Table， 也 包含 到 了 这 个 段 中 。 这 些 是 程 
序 加 载 和 重 定位 时 需要 的 信息 ， 随 着 讨论 的 深入 ， 我 们 慢 慢 就 会 理解 它们 
的 作用 。 


令 数据 段 (data segment) 具有 读 写 权限 ， 除 了 典型 保存 数据 的 Section 
外 ， 一 些 具有 读 写 权限 的 Section， 如 GOT 表 ， 也 包含 到 这 个 段 中 。 


除了 这 两 个 LOAD 类 型 的 Segment 外 ，ELEF 规 范 还 规定 了 几 个 其 他 的 
Segment， 它 们 都 是 辅助 加 载 的 。 仔 细 观 察 Program Header Table， 我 们 会 发 
现 ， 其 他 类 型 的 Segment 都 包括 在 LOAD 类 型 的 段 中 。 所 以 ， 在 加 载 时 ， 内 
核 只 需要 加 载 LOAD 类 型 的 Segment 。 


内 核 中 加 载 ELF 可 执行 文件 的 代码 如 下 : 


Linuxs3.7 .0/6/Dintmt lf ses 


statis nt load elf binary(struet, linux blinpin. *bprEm, wd) 


{ 


if (memcmp (loc->elf ex.e ident, ELFMAG, SELFMAG) != 0) 


goto out; 
retval = kernel read (bprm->file, loc->elf ex.e phoff, 


(char *)elf phdata,; size); 


for(li = 0, elf ppnt = elf phdata; 
i < loc->elf ex.e phnum; i++, elf ppnt++) { 


if (elf ppnt->p type != PT LOAD) 
continue; 


error = elf map (bprm->file, load bias + vaddr, elf ppnt, 


Elf TI, ef Mage 0)' 


1) 函数 load_elf binary 首 先 检 测 文件 头 部 信息 ， 判 断 是 否 是 ELF 类 型 的 
文件 ， 包 括 进一步 检测 是 否 是 ELF 的 可 执行 文件 或 者 动态 库 等 。 


2) 经 过 一 致 性 检查 ， 如 果 确 认 是 ELF 可 执行 文件 ，load_elf_binary 读 入 
Program Header Iable。 


3) load_elf_binary 遍 历 Program Header Table， 调 用 画 数 elf_map 映 射 类 
型 为 PT_ LOAD 的 段 到 进程 地 址 空间 。elf_map 为 每 个 段 创建 一 个 
vm_area_struct 对 象 ， 其 第 二 个 参数 就 是 段 在 进程 地 址 空间 中 映射 的 地 址 ， 

这 个 地 址 在 编译 时 链接 器 就 已 经 分 配 好 了 。 加 载 偏 移 load_bias 是 用 于 动态 库 
的 ， 对 于 可 执行 文件 来 说 ，load_bias 值 是 0。 


事实 上 ， 除 了 映射 ELF 文 件 中 的 段 到 进程 地 址 空间 外 ， 内 核 还 创建 了 其 
他 几 个 进程 运行 时 必 不 可 少 的 段 ， 包 括 BSS、 栈 和 堆 三 个 匿名 段 ， 以 及 为 动 
态 库 及 文件 映射 预 留 的 内 存 映 射 区 域 ， 这 个 区 域 中 一 般 包含 多 个 段 。 


(1) 栈 段 


起 初 ， 内 核 将 栈 安排 在 用 户 空 间 的 最 顶端 ， 即 栈 底 在 0xc0000000。 后 
来 为 了 安全 起 见 ，Linux 使 用 了 ASLR (Address Space Layout 
Randomization) 技术 。ASLR 是 一 种 针对 缓冲 区 溢出 的 安全 保护 技术 ， 在 进 
程 的 地 址 空间 中 ， 堆 、 栈 、 内 存 映射 等 段 不 再 分 配 固定 的 地 址 ， 而 是 在 每 
次 进程 启动 时 ， 在 原来 的 位 置 上 加 上 一 个 随机 的 偏 移 ， 增 加 攻击 者 确定 这 
些 段 的 位 置 的 难度 ， 从 而 达到 阻止 溢出 攻击 的 目的 。 


创建 栈 段 的 vm_area_struct 对 象 的 代码 如 下 : 


linux-3.7.4/fs/exec.c: 


static int _ bprm mm init (struct linux binprm *bprm) 


{ 
bprm->vma = vma = kmem cache zalloc(vm area cachep, ...); 


vma->vm end = STACK TOP MAX; 
vma->vm start = vma->vm end - PAGE SIZE; 


} 


函数 _bprm_mm_init 为 栈 创建 了 一 个 vm_area_struct 对 象 ， 栈 的 初始 大 
小 是 一 个 页 面 (PAGE_SIZE) ， 栈 底 在 STACK_TOP_MAX 。 安 


STACK_TOP_MAX 的 值 如 下 : 


linux-3.7.4/arch/x86/include/asm/processor.h: 


#define TASK SIZE PAGE OFFSET 

#define TASK SIZE MAX TASK SIZE 
#define STACK TOP TASK SIZE 
#define STACK TOP MAX STACK TOP 


其 中 PAGE_OFFSET 的 值 就 是 内 核 在 进程 空间 中 的 偏 移 ， 即 


0xc0000000， 世 就 是 用 户 空间 的 最 顶端 。 但 是 接 下 来 在 将 参数 、 环 境 变 量 
所 在 的 页 面 映射 到 新 进程 的 栈 空间 时 ， 内 核对 栈 段 的 位 置 进行 了 随机 化 处 


理 ， 代 码 如 下 : 


linux-3.7.4/fs/binfmt elf.c: 


static int load elf binary(struct linux binprm *bprm, ,...) 


{ 


retval = setup arg pages (bprm, 
randomize stack top(STACK TOP), executable stack); 


} 


linux-3.7.4/fs/exec.c: 


int setup arg pages(struct linux binprm *bprm, 。,.) 


{ 


stack top = arch align stack(stack top); 


x86 架 构 的 函数 arch_align_stack 的 代码 如 下 : 


linux-3.7.4/arch/x86/kernel/process.c: 
unsigned long arch align stack (unsigned long sp) 


if (!(current->personality & ADDR NO RANDOMIZE) && 
randomize va space) 
sp -= get random int() % 8192:; 
return sp & ~0xf,; 


} 


根据 其 中 使 用 黑体 标识 的 部 分 可 见 ， 栈 段 的 地 址 被 进行 了 随机 处 理 。 
另外 ， 注 意 if 条 件 中 的 变量 randomize_va_space， 用 户 可 以 通过 proc 文 件 系 统 
中 的 接口 改变 这 个 变量 ， 从 而 可 以 动态 控制 内 核 的 这 个 特性 。 


在 程序 运行 时 ， 当 进行 压 栈 操 作 时 ， 如 果 栈 空间 不 足 ， 将 引起 缺 页 中 
晰 。 缺 页 中 断 处 理 函 数 调用 函数 expand_stack 扩 展 栈 段 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/mm/fault.c: 


static void kprobes _do page fault (struct pt regs *regs, ...) 
{ 
if (unlikely (expand stack(vma, address))) { 
} 
1 
(2) BSS 段 


BSS 段 保存 的 是 未 初始 化 的 数据 ， 所 以 BSS 段 并 不 需要 从 文件 中 读 取 数 
据 ，BSS 也 并 不 需要 映射 到 文件 ， 故 BBS 段 也 是 一 个 匿名 映射 段 。 但 是 注意 
一 点 ， 并 不 是 每 个 进程 都 需要 创建 BSS 段 。 如 果 程 序 中 根本 就 没有 未 初始 化 
数据 ， 那 么 自然 就 不 需要 创建 BSS 段 。 或 者 程序 中 未 初始 化 数据 占据 的 空间 
被 数据 段 的 对 齐 部 分 覆盖 ， 也 不 需要 创建 数据 段 。 假 设 可 执行 文件 中 数据 
段 的 结束 地 址 为 : 


0X804a028 


按照 数据 段 的 页 对 齐 要求 ， 在 进程 地 址 空间 中 对 齐 后， 数据 段 的 结束 
地 址 为 : 


0x804b000 


如 果 从 0x804a028 到 0x804b000 之 间 的 这 上 段 空间 已 经 覆盖 了 全 部 的 未 初 
台 化 数据 ， 那 么 就 不 必 再 创建 BSS 段 了 。 


函数 load_elf_binary 中 创建 BSS 段 的 相关 代码 如 下 : 


linux-3.7.4/f8/binfmt elf.c: 


O01 ‘statue Lnt lo6ad: elf blinary (wl 


Gg "f{ 

03 wt 

04 Struct ‘elf phdr *elf ppnts *elf phdata; 

05 和 

06 elf bss = 0; 

07 elf brk = 0; 

08 

09 for(i = 0, elf ppnt = elf phdata; 

10 i < loc->elf ex.e phnum; i++, elf ppnt++) { 
1 i 

1 k = elf ppnt->p vaddr + elf ppnt->p filesz; 
13 

14 if (k > elf bss) 

15 elf bss = k; 

16 x 

Tm k = elf ppnt->p vaddr + elf ppnt->p memsz; 
18 if (k > elf brk) 

19 elf brk = k; 

20 } 

下 i 

22 retval = set brk(elf bss, elf brk); 

3 De 


代码 第 9~20 行 遍历 ELF 文 件 的 Program Header Table， 其 中 elf _phdr 是 指 
向 表 Program Header Table 中 的 Program Header 的 指针 ，elf_ppnt->p_vaddr 是 
段 在 进程 地 址 空间 中 的 起 始 地 址 ，elf_ppnt- > p_filesz 是 段 在 ELF 文 件 中 占据 
的 尺寸 ，elf_ppnt->p_memsz 记 录 的 是 段 在 内 存 中 占据 的 尺寸 。 


对 于 ELF 可 执行 程序 而 言 ， 这 个 for 循 环 将 循环 两 次 ， 第 一 次 映射 代码 
段 ， 第 二 次 映射 数据 段 。 因 此 ， 在 第 二 次 循环 后 ， 第 12 行 代码 中 的 变量 k 的 
值 是 数据 段 的 起 始 地 址 (VirtAddr) 与 数据 段 (不 包含 BSS) 的 大 小 
(FileSiz) 的 和 ， 并 在 第 15 行 代码 将 这 个 值 记 录 在 变量 elf_bss 中 。 第 17 行 代 
码 中 变量 k 的 值 是 数据 段 的 起 始 地 址 (VirtAddr) 与 数据 段 (包含 BSS) 的 大 
小 (MemSiz) 的 和 ， 并 在 第 19 行 记录 在 变量 elf_brk 中 。 显 然 ，elf_bss 指 向 
不 包含 BSS 数 据 的 数据 段 的 结束 位 置 ， 而 elf_brk 指 向 包含 BSS 数 据 的 数据 段 
的 结束 位 置 。 然 后 ，load_elf_binary 调 用 函数 set_brk 比 较 elf_bss 和 elf_brk 。 


看 到 brk 这 个 词 是 不 是 有 点 似曾相识 ? 没 错 ，brk 就 是 program break， 即 代表 
程序 动态 申请 地 址 的 上 限 。 那 么 BSS 段 和 brk 有 关系 吗 ? 为 什么 在 映射 BSS 
段 时 出 现 了 brk? 当然 有 ， 因 为 BSS 段 的 末尾 就 是 brk 的 起 始 地 址 。 画 数 
set_brk 的 代码 如 下 : 


linux-3.7.4/f8/binfmt elf.c:; 
static int set brk(unsigned long start, unsigned long end) 
{ 
start = ELF PAGEALIGN (start); 
end = ELF PAGEALIGN (end); 
if (end > start) { 
unsigned long addr; 
addr = Vm brk (start, end = start};} 
if (BAD ADDR (addr)) 
return addr; 
} 


current->mm->start brk = current->mm->brk = end; 
return 0; 


set_brk 对 比 经 过 页 对 齐 后 的 elf_bss 和 和 elf_brk。 如 果 对 齐 后 前 者 不 能 泣 盖 
后 者 ， 则 调用 函数 vm_brk 创 建 单 独 的 BSS 段 ， 为 BSS 段 创建 一 个 


vm_struct_area 对 和 象 。 


结构 体 mm_struct 中 的 start_brk 用 来 记录 堆 段 的 起 始 位 置 ， 变 量 brk 记 采 
堆 段 的 结束 位 置 。 根 据 函 数 set_brk 的 代码 可 见 ， 初 始 化 时 ， 堆 的 起 始 位 置 
和 结束 位 置 都 是 BSS 段 的 结束 位 置 。 在 程序 动态 申请 内 存 时 ， 内 核 再 按 需 扩 
展 堆 的 大 小 。 


(3) 堆 段 


扒 段 映射 的 内 存 是 进程 运行 时 动态 分 配 的 ， 所 以 在 建立 进程 的 地 址 罕 
间 时 ， 只 需 确 定 堆 段 的 起 始 位 置 即 可 。 根 据 前 面 讨 论 的 函数 set_brk， 初 始 
时 ， 堆 的 起 始 位 置 和 结束 位 置 都 指向 BSS 段 的 结束 位 置 。 在 进程 运行 时 ， 根 
据 程 序 动态 申请 内 存 情 况 动态 的 调整 堆 的 大 小 。 比 如 程序 调用 C 库 的 


malloc/free 芳 数 动 态 分 配 和 释放 内 存 时 ， 事 实 上 就 是 通过 内 核 的 系统 调用 
brk/sbrk 动 态 改变 堆 的 大 小 。 


出 于 安全 的 原因 ， 堆 段 也 使 用 了 ASLR 技 术 ， 所 以 这 个 位 置 一 般 并 不 紧 
接 在 BSS 的 后 面 ， 而 是 又 加 了 一 个 随机 的 偏 移 ， 代 码 如 下 


linux-3.7.4/fs/binfmt elf.c: 
static int load elf binary(struct linux: binprm *bprm; wa) 


{ 


if((current->flags & PF RANDOMIZE) && (randomize va space > 1)){ 
current->mm->brk = current->mm->start brk = 
arch randomize brk(current->mm); 


根据 上 面 的 代码 可 见 ， 如 果 变 量 randomize_va_space 的 值 大 于 1， 则 调用 
体系 结构 相关 的 函数 arch_randomize_brk 将 start_brk 和 brk 调 整 到 一 个 随机 的 
值 。IA32 染 构 中 的 函数 arch_randomize_btk 实 现 如 下 : 


linux-3.7.4/arch/x86/kernel/process.c: 
unsigned long arch randomize brk(struct mm struct *mm) 


{ 


unsigned long range end = mm->brk + 0x02000000; 
return randomize range (mm->brk, range end, 0) ? : mm->brk; 


内 核 在 proc 中 为 用 户 提供 了 一 个 接口 ， 允 许 用 户 修改 变量 
randomize_va_space， 从 而 可 以 动态 控制 内 核 的 这 个 特性 。 


(4) 内 存 有 映射 区 域 


进程 空间 中 还 专门 留 有 一 个 区 域 用 于 内 存 映射 ， 比 如 文件 上 映射、 共享 
内 存 等 ， 动 态 库 就 映射 在 这 个 区 域 。 内 存 映射 区 域 一 般 包含 多 个 
vm_struct_area 对 象 。 比 如 一 个 程序 依赖 多 个 动态 库 ， 那 么 就 会 有 多 个 动态 
库 映 射 到 这 里 。 而 且 即 使 十 同一 个 动态 库 ， 也 存在 着 如 代码 段 、 数 据 段 等 


多 个 段 。 


对 于 x86 架 构 ， 在 2.4 版 本 时 ， 内 存 上 映射 区 域 的 起 始 地 址 是 固定 的 ， 在 内 
核 用 户 空间 的 /3 处 ， 即 0xc0000000/3=0x40000000。 从 2.6 版 本 以 后 ， 内 核 将 
这 个 区 域 安排 在 了 栈 段 的 下 方 。x86 架 构 下 确定 内 存 映 射 区 域 的 基 址 的 函数 
如 下 : 


linux-3.7.4/arch/x86/mm/mmap.c: 
void arch pick mmap layout (struct mm struct *mm) 
{ 

if (mmap is legacy()) { 


mm- >mmap _ base = mmap legacy base(); 


} else { 
mm->mmap base = mmap base(); 


} 
} 


在 函数 arch_pick_mmap_layout 中 ， 半 代码 块 中 对 应 的 就 是 内 核 传 统 的 
(2.4 版 本 ) 确定 内 存 映射 区 域 起 始 位 置 的 方法 ， 而 else 代 码 块 对 应 的 则 是 从 
2.6 版 本 开始 使 用 的 方法 。 根 据 代 码 可 见 ， 在 2.6 版 本 下 ， 确 定 这 个 位 置 的 函 
数 是 mmap_base， 其 代码 如 下 : 


linux-3.7.4/arch/x86/mm/mmap.c: 


01 static unsigned long mmap base (void) 


0 人 :4 

03 unsigned long gap = rlimit (RLIMIT STACK); 

04 

05 if (gap < MIN GAP) 

06 gap = MIN_ GAP; 

og7 else if (gap > MAX GAP) 

08 gap = MAX GAP; 

09 

10 return PAGE ALIGN(TASK SIZE - gap - mmap_ rnd()); 
Ld 


根据 第 3 行 代码 可 见 ， 内 核 取 出 进程 的 栈 的 上 限 ， 然 后 将 内 存 映 射 区 域 
安排 在 栈 的 下 方 。 内 核 默 认 进 程 栈 的 大 小 是 8MB， 但 是 每 个 进程 都 可 以 通 
过 系统 调用 ulimit 设 置 进程 的 各 项 资源 ， 包 括 栈 的 大 小 。 所 以 在 分 配 内 存 映 
射 的 基 址 时 ， 内 核 首先 尊重 进程 的 意愿 ， 调 用 rlimit 读 取 了 进程 设置 的 栈 的 
上 限 。 但 是 ， 内 核 可 不 能 由 着 用 户 的 性 子 来 ， 和 毕竟 资 源 有 限 ， 内 核 还 要 判 
岂 用 户 设置 的 栈 空间 是 否 合理 ， 这 就 是 代码 第 5~8 行 的 目的 。 我 们 看 到 ， 内 
核 要 求 进程 空间 中 ， 栈 的 最 小 尺寸 是 MIN_GAP， 而 最 大 尺寸 是 
MAX_GAP。 这 两 个 宏 的 定义 如 下 : 


linux-3.7.4/arch/x86/mm/mmap.c: 


#define MIN GAP (128*1024*1024UL + stack maxrandom size()) 
#define MAX GAP (TASK SIZE/6*5) 


可 见 ， 内 核 给 栈 预 留 的 空间 最 小 是 128MB， 最 大 古 


TASK_SIZE/6*5=3GB/6*5=2.5GB ° 


最 后 ， 内 核 调用 函数 mmap_md 计 算 了 一 个 随机 的 偏 移 ， 加 在 了 内 存 映 
员 的 基 址 上 ， 见 第 10 行 代码 。 也 就 是 说 ， 内 存 映 映 区 域 ， 内 核 也 使 用 了 


ASLR 技 术 。 


进程 的 地 址 空间 大 致 如 图 5-22 所 示 。 
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图 5-22 进程 的 地 址 空间 示意 图 


在 图 5-22 中 ， 进 程 地 址 空间 中 有 效 的 部 分 使 用 实 线 标 出 ， 虚 线 部 分 是 疝 
未 映射 的 部 分 。 因 为 数据 段 可 能 涵盖 了 BSS， 所 以 映射 BSS 的 vm_area_struct 


对 象 也 使 用 虚线 标 出 ， 表 示 在 程序 映射 时 ， 可 能 并 不 会 建立 BSS 段 。 男 外 ， 
在 内 存 映 射 区 域 ， 图 中 只 示意 性 地 列 出 了 C 库 和 动态 链接 器 中 的 部 分 段 的 映 
射 ， 其 他 段 的 映 丑 并 没有 列 出 ， 所 以 也 使 用 了 一 个 虚线 标 出 的 
vm_area_struct 对 和 象 代表 其 他 的 映 冉 。 


， 我 们 以 可 执行 程序 hello 为 例 ， 具 体 观察 一 下 进程 的 地 址 空间 。 


首先 来 看 一 下 hello 的 Program Header Table: 


root@baisheng:~/demo# readelf -1 hello 


Program Headers: 
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align 
PHDR Ox000034 0x08048034 0x08048034 0x00120 0x00120 R E Ox4 
INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0X1 


[Requesting program interpreter: /lib/ld-linux.so.2] 


LOAD Ox000000 0x08048000 0x08048000 0x0079c Ox0079c R E Ox1000 
LOAD 0x000f00 0x08049f00 0x08049f00 0x0012C 0x02160 RW 0x1000 

DYNAMIC Ox000f0c 0x08049f0c 0x08049f0c 0x000f0 0x000f0 RW 0x4 
NOTE Ox000168 0x08048168 0x08048168 0x00044 0xXx00044 及 0X4 


GNU EH FRAME Ox0006a8 0x080486a8 0x080486a8 0x00034 0x00034 R Ox4 
GNU STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 
GNU RELRO 0x000f00 0x08049f00 0x08049f00 0x00100 0x00100 R 0x1 


虽然 hello 的 Program Header Table 中 包含 了 多 达 9 个 段 ， 但 是 正如 我 们 前 
面谈 到 的 ， 其 中 只 有 类 型 为 LOAD 的 段 才 会 被 映射 进 内 存 。hello 中 包含 两 个 
类 型 为 LOAD 的 段 ， 根 据 "Flg" 一 列 可 见 ， 第 一 个 LOAD 类 型 的 段 具 有 读 和 可 
执行 权限 (RE) ， 映 射 为 进程 中 的 代码 段 ， 第 二 个 LOAD 类 型 的 段 具 有 读 
写 权 限 (RW) ， 了 映射 为 进程 中 的 数据 段 。 事 实 上 ，LOAD 类 型 的 段 已 经 涵 
盖 了 全 部 ELF 文 件 中 需要 加 载 进 内 存 的 部 分 。 其 他 几 个 段 完 全 是 为 了 辅助 加 
载 用 的 ， 要 么 包含 在 代码 段 中 ， 要 么 包含 在 数据 段 中 。 


代码 段 的 起 始 地 址 是 0x08048000， 结 束 地 址 是 
0x08048000+0x0079c=0x804879c。 根 据 列 "Align" 可 见 代 码 段 要 求 4KB 对 
齐 ， 起 始 地 址 已 经 是 4KB 对 齐 的 ， 无 须 调 整 ， 而 结束 地 址 则 需要 从 
0x804879c 调 整 为 0x8049000 。 


数据 段 的 起 始 地 址 是 0x08049f00， 结 束 地 址 是 
0x08049f00+0x0012c=0x0804a02c。 根 据 列 "Align" 可 见 数据 段 也 要 求 4KB 对 
齐 ， 所 以 数据 段 的 起 始 地 址 需要 调整 为 0x08049000， 结 束 地 址 需要 调整 为 
0x0804b000。hello 的 BSS 段 为 8244 字 节 (0x02160~0x0012c) ， 显 然 数据 段 
对 齐 的 那 部 分 已 经 不 能 涵盖 未 初始 化 数据 了 ， 因 此 需要 创建 一 个 单独 的 BSS 


段 。 


下 面 我 们 将 hello 程 序 运行 起 来 ， 结 合 前 面 的 理论 分 析 ， 实 际 观察 一 下 
其 进程 地 址 空间 的 映射 。 


root@baisheng:~/demo# ./hello & 


[1] 4822 


root@baisheng:~/demo# cat /proc/4822/maps 


08048000-08049000 
08049000-0804a000 
0804a000-0804b000 
0804b000-0804d000 
0985e000-0987f000 
b75a4000-b75a5000 
b75a5000-b75a6000 
b75a6000-b75a7000 
b75a7000-b75a8000 
b75a8000-b75a9000 
b75a9000-b774c000 


r-xp 00000000 08: 
r--p 00000000 08: 
rw-p 00001000 08: 
rw-p 00000000 00: 
rw-p 00000000 00: 
rw-p 00000000 00: 
r-xp 00000000 08: 
r--p 00000000 08: 
rw-p 00001000 08: 
rw-p 00000000 00: 
r-xp 00000000 08: 


01 
01 
01 
00 
00 
00 
01 
01 
01 
00 
01 


1054223 /root/demo/hello 
1054223 /root/demo/hello 
1054223 /root/demo/hello 
0 

0 [heap] 

0 

1054350 /root/demo/libf2.so 


1054350 /root/demo/libf2.so 
1054350 /root/demo/libf2.so 
0 

S23358 


/lib/i386-linux-gnu/libc-2.15.so 
b774c000-b774d000 ---p 001a3000 08:01 523958 
/lib/i386-linux-gnu/libc-2.15.so 
b774d000-b774£f000 Yr--p 001a3000 08:01 523958 
/lib/i386-linux-gnu/libc-2.15.so 
b774f000-b7750000 rw-p 001a5000 08:01 523958 
/lib/i386-linux-gnu/libc-2.15.so 


b7750000-b7753000 
b7768000-b7769000 
b7769000-b776a000 
b776a000-b776b000 
b776b000-b776d000 
b776d000-b776e000 
b776e000-b778e000 


b778e000-b778f000 
b778f000-b7790000 


bf92a000-bf94b000 


根据 输出 可 见 : 


1) 地 址 范围 0x08048000~0x08049000 具 有 读 和 可 执行 权限 ， 显 


进程 的 代码 段 。 


rw-p 00000000 00 : 
r-xp 00000000 08 : 
r--p 00000000 08: 
rw-p 00001000 08: 
rw-p 00000000 00: 
r-xp 00000000 00: 
r-xp 00000000 08: 
/lib/i386-linux-gnu/1d-2.15. 
r--p 0001f000 08: 
/lib/i386-linux-gnu/1d-2.15. 
rw-p 00020000 08: 
/lib/i386-linux-gnu/1d-2.15. 
rw-p 00000000 00: 


00 
81 
01 
01 
00 
00 
01 
SO 
01 
SO 
01 
SO 
00 


0 
1047105 /root/demo/libf1.so 
1047105 /root/demo/1Libfl.so 
1047105 /rzoot/demo/lLibfl.so 
0 


0 [vdso] 
523936 

523936 

523936 

0 [stack] 


然 训 


1%W HY 


> 日 
LXE 


2) 地 址 范围 0x0804a000~0x0804b000 具 有 读 写 权限 ， 是 进程 的 数据 


段 。 


3) 在 代码 段 和 数据 段 之 间 映 射 了 一 个 只 读 的 段 : 
0x08049000~0x0804a000。 虽 然 这 个 段 是 读 的 ， 但 是 广义 上 其 属于 数据 段 ， 


这 个 只 不 过 是 从 数据 段 中 划分 的 一 个 子 段 ， 称 为 段 RELRO， 读 者 可 暂 不 关 
心 ， 我 们 在 5.4.9 节 会 讨论 进程 至 间 映射 这 个 段 的 缘由 。 


4) 地 址 范围 0x0804b000~0x0804d000 具 有 读 写 权限 ， 而 且 是 个 匿名 映 
射 段 ， 紧 接 在 数据 段 后 面 ， 而 且 正 好 占据 8KB 大 小 的 空间 ， 我 想 读 者 已 经 
猜 到 了 ， 其 融 是 保存 程序 hello 中 未 初始 化 的 全 局 数组 a[2048] 的 BSS 段 。 读 
者 可 以 做 个 实验 ， 去 掉 程 序 hello.c 中 的 这 个 数组 ， 然 后 重新 编译 运行 ， 就 可 
发 现 hello 进 程 将 无 需 再 映射 单独 的 BSS 段 。 


5) 地 址 范围 0x0985e000~0x0987f000 具 有 读 写 权限 ， 显 然 也 是 保存 数据 
的 ， 根 据 后 面 的 字 串 "heap"， 读 者 应 该 可 以 猜 到 ， 这 个 段 是 hello 进 程 的 堆 
段 。 读 者 也 可 作 个 实验 ， 去 掉 程 序 hello.c 中 使 用 mallo 动 态 分 配 的 1024 个 字 
节 ， 然 后 重新 编译 运行 ， 就 可 发 现 堆 段 也 将 不 再 被 映射 。 前面 我 们 谈 到 
过 ， 堆 是 程序 运行 时 动态 分 配 的 ， 所 以 如 果 程 序 中 尚未 在 堆 中 申请 变量 ， 
内 核 将 不 会 主动 为 进程 映射 堆 段 ， 只 是 首先 确定 好 堆 的 基 址 ， 在 需要 时 按 
需 动态 映射 。 


6) 接 下 来 ， 怠 是 一 个 大 的 内 存 映 射 区 域 了 : 
0xb75a4000~0xb7790000， 在 这 个 区 域 中 ， 映 射 了 C 库 、 动 态 链接 句 以 及 动 
态 库 libf1 和 1libf2。 对 于 每 个 动态 库 来 说 ， 其 映射 过 程 与 可 执行 程序 并 无 本 质 
差别 ， 仔 细 观 察 ， 可 以 发 现 ， 每 个 动态 库 也 有 自己 的 代码 段 、 数 据 段 等 ， 
其 具体 映射 过 程 我 们 在 加 载 动 态 库 一 站 再 讨论 。 


7) 进程 空间 中 最 后 映射 的 一 个 段 : 0xbf92a000~0xbf94b000， 具 有 读 写 
权限 ， 也 是 保存 数据 的 ， 根 据 后 面 输出 字 串 "stack" 可 知 ， 这 个 段 就 是 栈 段 。 


最 后 ， 我 们 留意 栈 段 的 起 始 地 址 : 0xbf94b000。 理 论 上 ， 栈 底 应 该 在 用 
户 空 间 的 最 顶端 ， 即 0xc0000000， 但 是 为 什么 不 是 这 个 地 址 呢 ? 请 读者 回 
想 一 下 我 们 前 面谈 到 的 ASLR 技 术 ， 栈 确 在 0xc0000000 的 基础 上 减 去 了 一 个 
随机 的 偏 移 。 


与 此 相仿 的 还 有 堆 段 和 内 存 映射 部 分 。 读 者 可 以 做 个 实验 ， 多 次 局 动 
hello 程 序 ， 你 会 发 现 ， 每 次 这 几 个 段 的 起 始 地 址 全 都 不 同 。 每 次 进程 局 动 
时 ， 都 会 在 原来 的 理论 地 址 上 ， 再 加 了 一 个 随机 的 偏 移 。 


内 核 在 proc 文 件 系 统 中 为 用 户 提供 了 一 个 接口 ， 允 许 用户 动 态 控制 是 否 
使 用 ASLR 技 术 。 这 个 接口 可 以 接收 3 个 参数 : 0 代表 关闭 ASLR 技 术 ; 1 代表 
内 存 映射 区 域 、 栈 和 vdso 段 的 起 始 地 址 是 随机 的 ; 2 表示 堆 段 起 始 地 址 也 是 
随机 的 。 以 笔者 的 机 融 为 例 ， 其 默认 值 为 2: 


root@baisheng:~# cat /proc/sys/kernel/randomize va Space 
2 


读者 可 以 采用 下 面 的 方法 ， 关 闭 ASLR: 


root@baisheng:~# echo 0 > /proc/sys/kernel/randomize va space 


然后 ， 即 使 多 次 启动 同一 个 程序 ， 但 是 这 几 个 段 的 地 址 也 不 再 随机 变 
动 了 。 


内 核 还 保留 了 2.4 版 本 的 分 配 内 存 映 射 区 域 的 方法 ， 用 户 也 可 以 通过 下 
面 的 方法 使 用 传统 的 方法 : 


root@baisheng:/proc/sys# echo 1 > /proc/sys/vm/legacy va layout 


使 用 下 面 的 命令 关闭 传统 的 内 存 映射 机 制 : 


root@baisheng:/proc/sys# echo 0 > /proc/sys/vm/legacy va layout 


限于 篇 幅 ， 我 们 就 不 再 一 一 列 出 开启 和 关闭 这 些 参数 后 ， 进 程 空间 的 
映射 情况 ， 读 者 可 自行 进行 这 些 非常 有 趣 的 实验 。 


5.4.2 ”进程 的 投入 运行 


丑 媚 妇 总 是 要 见 公 奖 的， 进程 最 终 一 定 征 要 切换 到 用 户 空间 的 ， 进 程 1 
也 躲 不 过 去 。 在 内 核 创 建 进程 1 时 ， 进 程 0 是 当前 进程 ， 因 此 ， 进 程 1 要 "“ 回 
到 ?用户 空间 ， 需 要 经 过 两 个 步骤 : 


1) 要 将 进程 0 赶 出 CPU。 也 就 是 在 内 核 空间 ， 进 程 1 要 “恢复 ”为 当前 进 
程 ， 这 是 进程 1“ 返 回 * 用 户 空间 的 前 提 条 件 。 


2) 进程 1 从 内 核 空 间 “ 回 到 ”用 户 空间 。 


显然 ， 从 进程 0" 恢 复 ”到 进程 1 需要 进程 1 在 内 核 空 间 的 现场 ， 进 程 1 从 
内 核 空间 “ 回 到 ”用 户 空 间 需 要 进程 1 在 用 户 空间 的 现场 。 但 是 ， 事 实 上 , 不 
仅 古 进程 1， 对 于 所 有 刚刚 创建 的 进程 ， 它 们 并 没有 经 历 过 从 用 户 空 间 切 到 
内 核 空间 ， 然 后 在 内 核 空间 被 其 他 进程 抢占 的 过 程 ， 哪 里 来 的 保护 现场 ? 
所 以 ， 殊 需要 操作 系统 助 它们 一 辟 之 力 ， 人 为 地 为 新 创建 的 进程 伪造 现 
场 。 


这 一 市， 我 们 首先 来 看 看 在 这 两 次 转换 过 程 中 ， 保 护 现 场 的 原理 。 然 
， 我 们 再 来 讨论 内 核 是 如 何在 原理 的 指引 下 伪造 这 两 个 现场 的 。 事 实 
上 ， 不 仅 进程 1 如 此 ， 其 他 进程 也 如 此 ， 这 里 的 讨论 适用 于 所 有 进程 。 


Th 


1. 用 户 现 场 的 保护 


我 们 通过 讨论 一 个 进程 从 用 户 空 间 切 换 到 内 核 空间 来 观察 用 户 现场 是 
如 何 保护 的 。 


(1) 从 用 户 栈 切 换 到 内 核 栈 


当 一 个 进程 正在 用 户 空 间 运 行 时 ， 一 旦 发 生 中 断 ， 那 么 进程 将 从 用 户 
空间 切换 到 内 核 空间 运行 。 进 程 在 内 核 空间 运行 时 ，CPU 各 个 寄存 右 同 样 
将 被 使 用 ， 因 此 ， 为 了 在 处 理 完 中 断后 ， 程 序 可 以 在 用 户 空间 的 中 断 处 得 
以 继续 执行 ， 需 要 在 穿越 的 一 刻 保护 这 些 寄存 器 的 值 ， 以 免 被 覆盖 ， 即 所 
谓 的 保护 现场 。Linux 使 用 进程 的 内 核 栈 保存 进程 的 用 户 现 场 。 因 此 ， 在 中 
断 时 ，CPU 做 的 第 一 件 事 就 是 将 栈 从 用 户 栈 切换 到 内 核 栈 ， 如 图 5-23 所 示 。 
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图 5-23 从 用 户 栈 切换 到 内 核 栈 


Intel 从 硬件 层面 设计 了 TSS 段 (task-state segment) 支持 任务 的 管理 ， 
其 中 记录 了 任务 的 状态 信息 。 既然 是 一 个 段 ， 每 个 TSS 也 在 GDT 中 占据 一 个 
表 项 。 如 同 代码 段 将 段 选择 子 保存 在 寄存 器 CS 中 ，CPU 要 求 将 TSS 段 选择 
子 保存 在 专用 寄存 器 TR (Task Register) 中 。 


Intel 建 议 为 每 一 个 进程 准备 一 个 独立 的 TSS 段 ， 每 当 任务 切换 时 ， 更 换 
CPU 中 TR 寄存 器 指向 当前 任务 的 TSS 段 。 天 下 没有 人 免费 的 午餐 ， 方 便 的 代 
价 束 古 效率 的 低下 。 而 事实 上 ， 任 务 切换 时 ， 本 不 必 保 存 如 TSS 中 包含 的 如 
此 复杂 的 上 下 文 ， 而 且 TR 寄 存 需 的 格式 比较 特殊 ， 远 非 直接 厂 入 一 个 地 址 


那么 简单 ， 还 需要 进行 一 些 计算 ， 因 此 切换 TR 的 代价 也 比较 大 。 因 此 ， 
Linux 并 没有 使 用 TSS 段 保存 任务 状态 信息 。 


但 是 当中 断 发 生 时 ，CPU 自 动 从 任务 寄存 器 TR 中 找到 TSS 段 ， 然 后 从 
该 段 中 装载 s 和 esp。“ 我 的 地 盘 听 我 的 ”， 所 以 Linux 还 要 遵从 Itel 的 “ 霸 
王 ” 条 款 ， 必 须 得 使 用 TSS。 但 是 Linux 处 理 得 比较 巧妙 ， 其 并 没有 为 每 个 任 
务 设计 一 个 TSS 段 ， 而 是 为 每 个 CPU 准 备 一 个 TSS 段 。 内 核 只 是 在 初始 化 阶 
段 设置 TR， 使 之 指向 一 个 TSS 段 ， 从 此 以 后 永 不 改变 TR 的 内 容 。TSS 段 的 
初始 内 容 如 下 : 


linux-3.7.4/arch/x86/include/asm/processor.h: 


#define INIT TSS { \ 

:X86 tss = 1{ NS 
.Sp0 = sizeof (init stack) + (long)¢&init stack, \ 
.Ss0 = __ KERNEL DS, \ 
:Ba = __ KERNEL CS, \ 
.io bitmap base = INVALID IO BITMAP OFFSET, \ 

}, \ 

.io bitmap = { [0 ... IO BITMAP LONGS] = ~0 }, \ 


内 核 初始 化 时 ， 在 画 数 cpu_init 中 初始 化 了 TR 寄存 器 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/kernel/cpu/common.c: 
volid ‘pulnit, pu dnit(vold) 
{ 
struct tss struct *t = &per cpul(init tss, cpu); 


set tss desc(cpu, 七 ) ; 
load TR desc(); 


其 中 ， 函 数 set_tss_desc 设 置 GDT 中 的 TSS 段 的 描述 符 ， 函 数 
load TR_desc 设 置 TR 寄存 器 。 


虽然 TSS 不 需要 切换 了 ， 但 是 TSS 中 的 ss 和 sp0 却 需要 随 着 任务 的 切换 ， 
走马 灯 式 地 更 换 ， 记 录 下 一 个 投入 运行 的 任务 的 内 核 栈 的 ss 和 sp0。 这 样 ， 
就 保证 了 在 中 断 发 生 时 ，CPU 可 以 正确 地 从 TSS 中 加 载 当前 进程 内 核 栈 的 ss 
和 esp。 在 宏 INIT_TSS 中 ，TSS 段 中 记录 的 内 核 栈 的 ss0 被 设置 为 
”KERNEL_DS， 所 以 这 里 ss0 永 远 不 需要 改变 ， 只 需 切 换 sp0 即 可 。 可 见 ， 
TSS 是 “ 铁 打 的 营盘 ， 流 水 的 兵 ”。 


但 是 不 知道 读者 思考 过 没有 ， 当 中 断 发 生 时 ， 当 CPU 从 TSS 段 中 加 载 
ssS0 和 sp0 分 别 到 ss 和 esp 时 ， 尚 未 保存 用 户 现场 ， 那 么 此 时 保存 在 ss 和 esp 中 
的 用 户 栈 的 信息 岂 不 是 被 覆盖 了 ? Intel 的 工程 师 们 当然 清楚 这 一 点 ， 事 实 
上 上 ，CPU 在 加 载 内 核 栈 信息 前 ， 会 将 寄存 器 ss 和 esp 中 的 值 首 先 临 时 保存 到 
CPU 内 部 ， 除 了 保存 寄存 器 ss 和 esp 的 值 外 ，CPU 临 时 保存 的 还 包括 寄存 器 
eflags、cs、eip 中 的 值 。 


经 过 这 一 步 后 ， 进 程 已 经 完成 了 栈 的 切换 ， 进 程 在 向 内 核 空间 前 进 的 
道路 上 迈 出 了 第 一 步 。 


(2) 保存 用 户 空 间 的 现场 


切换 完 栈 后 ，CPU 在 进程 的 内 核 栈 中 保存 了 进程 在 用 户 空间 执行 时 的 
现场 信息 ， 包 括 eflags、cs、eip、ss 和 esp， 如 图 5-24 所 示 。 
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图 5-24 你 存 用 户 空间 的 现场 


在 进程 退出 内 核 空间 时 ， 中 段 处 理 函 数 最 后 会 调用 x86 的 指令 iret 将 CPU 
压 入 的 这 几 个 值 恢复 到 对 应 的 寄存 邵 中 。 


(3) 穿越 中 断 门 


返 下 来 ， 进 程 瑟 将 进行 最 后 的 穿越 了 ， 当 然 ， 内 核 在 初始 化 时 束 已 经 
为 CPU 初始 化 了 中 断 相 关 的 部 分 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/kernel/head 32.3: 


01 ENTRY (startup 32) 


02 NR 

03 lidt idt descr 

04 Sg 

05 setup once; 

06 movl1 $idt table,%edi 

07 mov]1 S$early_ idt handlers, %eax 

08 movl $NUM EXCEPTION VECTORS, Secx 

09 1 

10 movl] %Seax, (Sedi) 

1 movl %eax,4(%edi) 

12 movl $(0x8E000000 + _ KERNEL CS),2(%edi) 

13 addl] $9,%eax 

14 addl $8,%edi 

15 loop 1b 

16 

1i7 movl $256 - NUM EXCEPTION VECTORS, Secx 

18 movl $ignore int,s%edx 

19 movl $(_ KERNEL CS << 16),%eax 

Z0 mOVW %dx, Sax /* selector = 0x0010 = cs */ 
2 movw $0x8E00,%dx /* interrupt gate - dpl=0, present */ 
四 这 

23 movl1 %Seax, (Sedi) 

24 movl] %edx,4 ($edi) 

25 addl1 $8,%edi 

26 loop 2b 

27 

28 idt descr: 

29 -word IDT _ ENTRIES*8-1 # idt contains 256 entries 
30 “long idt table 


代码 第 6~26 行 初始 化 中 断 描 述 符 表 idt_table， 其 包含 256 项 ， 每 一 项 均 
是 一 个 64 位 的 描述 符 。CPU 运 行 过 程 中 ， 可 能 有 多 种 情况 需要 中 断 正在 执 
行 的 指令 ， 转 而 和 多 去 处 理 中 断 。 包 括 外 部 设备 来 的 信号 ， 或 者 是 执行 指令 
时 发 生 了 异 钊 ， 如 发 生 了 除数 是 0 的 情况 。 因 此 ， 中 断 描述 符 表 中 包括 几 种 
不 同 的 描述 符 ， 但 是 大 同 小 异 。 这 些 描述 符 也 被 称 为 门 描述 符 (gate 


descriptor) ， 以 中 断 门 为 例 ， 其 格式 如 图 5-25 所 示 。 
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图 5-25 中 断 门 格式 


对 于 图 5-25， 重 点 关注 其 中 两 个 字段 ， 一 个 是 "Segment Selector"， 这 个 


是 段 选 择 子 ， 也 就 是 对 应 这 个 中 断 的 处 理 函 数 所 在 的 段 ; 另外 一 个 
是 "Offset"， 其 表示 的 是 中 断 处 理 函 数 在 段 内 的 偏 移 。 因 为 Linux 使 用 的 是 平 
坦 内 存 模 式 ， 段 基 址 为 0， 所 以 实际 上 这 个 段 内 偏 移 承 是 中 断 处 理 函 数 的 地 


WE 


上 面 代码 中 包含 两 个 loop 循 环 ， 填 充 了 256 项 中 断 描 述 符 。 每 个 门 的 段 
选择 子 都 是 _KERNEL_CS， 只 有 中 断 处 理 函 数 不 同 。 前 
NUM_EXCEPTION_VECTORS 项 对 应 的 中 断 处 理 函 数 是 early_idt_handlers， 

其 余 项 的 中 断 处 理 函 数 是 ignore_int。 这 两 个 函数 都 是 内 核 初 始 化 早期 的 临 
时 中 断 处 理 函 数 ， 在 内 核 建 立 好 基本 环境 后 ， 会 使 用 真正 的 中 断 处 理 画 数 
替换 这 些 临 时 的 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/kernel/traps.c: 


void _ init trap init (void) 


{ 


Set_intzr_gate (X86_TRAP TS，&invalid_ TSS) ; 
set_ intr gate(X86 TRAP NP，&segment_not_PpPresent) ; 


中 断 描述 符 表 构建 完成 后 ， 内 核 还 需要 将 其 地 址 告诉 CPU，CPU 中 为 
此 设计 了 一 个 专用 寄存 器 idtr。 除 了 中 断 描述 表 的 地 址 外 ， 当 然 还 需要 将 这 
个 表 长 度 也 载 入 这 个 寄存 器 。x86 设 计 了 指令 lidt 来 加 载 idtr 寄 存 右 ， 见 函 才 


startup_32 代 码 中 的 第 3 行 。 


2 


洋 


了 解 了 中 断 门 的 数据 结构 后 ， 我 们 束 很 容易 理解 在 穿越 中 断 门 的 一 刹 
那 ，CPU 的 所 作 所 为 了 。CPU 和 首先 将 根据 寄存 怖 IDTR， 找 到 中 断 摘 述 符 
表 。 然 后 以 中 断 癌 量 作为 下 标 ， 在 中 断 描述 符 表 中 找到 对 应 的 门 ，CPU 将 
其 中 的 段 选择 子 加 载 到 寄存 右 cs， 将 其 中 的 侦 移 地 址 加 载 到 寄存 从 eip， 如 


图 5-26 所 示 。 
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图 5-26 穿越 中 断 门 


经 过 这 一 步 后 ， 进 程 彻底 的 穿越 到 了 内 核 空间 。 


因为 Linux 没 有 使 用 TSS， 所 以 除了 CPU 目 动 将 cs、eip 等 儿 个 寄存 器 压 
入 栈 外 ， 中 断 处 理 函 数 需要 将 其 他 的 寄存 夯 也 庄 和 内核 栈 ， 保 存 进程 完整 
的 用 户 空 间 的 现场 。 在 进程 退出 内 核 空 间 时 ， 中 段 处 理 函 数 人 负责 将 其 压 入 


栈 的 这 些 值 再 恢复 到 相应 的 寄存 部 中 。 


2. 内 核 现场 的 保护 


当 进 程 在 内 核 空间 运行 时 ， 在 发 生 进程 切换 时 ， 依 然 需要 保护 切换 走 
的 进程 的 现场 ， 这 是 其 下 次 运行 的 起 点 。 那么 进程 的 内 核 现 场 保存 在 哪里 
合适 呢 ? 前 面 我 们 看 到 进程 的 用 户 现场 保存 在 进程 的 内 核 栈 ， 那 么 进程 的 
内 核 现场 当然 也 可 以 保存 在 进程 的 内 核 栈 。 


但 是 ， 当 调度 函数 准备 切换 到 下 一 个 进程 时 ， 下 一 个 进程 的 内 核 栈 的 
栈 指针 从 何 而 来 ? 在 前 面 讨论 进程 从 用 户 空 间 切 换 到 内 核 空 间 时 ， 我 们 看 
到 ，CPU 从 进程 的 TSS 段 中 获取 内 核 栈 的 栈 指针 。 那 么 当 在 内 核 空 间 发 生 切 
换 时 ， 调 度 函 数 如 何 找到 准备 切入 进程 的 内 核 栈 的 栈 指针 ? 


除了 进程 的 内 核 栈 外 ， 进 程 在 内 核 中 始终 存在 另外 一 个 数据 结构 
进程 的 户口 ， 即 任务 结构 。 因 此 ， 进 程 的 内 核 栈 的 栈 指针 可 以 保存 在 进程 
的 任务 结构 中 。 在 任务 结构 中 ， 特 意 抽 象 了 一 个 结构 体 thread_struct 来 保存 
进程 的 内 核 栈 的 栈 指 针 、 返 回 地 址 等 天 键 信息 。 


调度 函数 使 用 宏 switch_to 切 换 进 程 ， 我 们 来 仔细 观察 以 下 这 段 代 码 ， 
为 了 看 起 来 更 清晰 ， 删 除了 代码 中 的 注释 : 


linux-3.7.4/arch/x86/include/asm/switch to.h: 


01 #define switch tol(prev, next, last) \ 

天 六 Di 汪汪 
03 asm volatile("pushfl\n\t" \ 

04 "pushl %%ebp\n\t" \ 
05 "mov1L %%esp,g%[prev sp]j\n\t" x 
06 "movl %[next sp],%%esp\n\t" NY 
07 "movl $1f, Slprev ip] \n\t" 
08 "pushl %[next ip]\n\t" A 
09 __ Switch canary 性 


0 "mB switeh to\n" \ 
二 二 mi NE \ 
J "popl %%ebp\n\t" 
| "popflNnn \ 
14 A \ 
工 5 : [prev sp] "=m" (prev->thread.sp), \ 
16 [prev_ip] "=m" (prev->thread.ip), SN 
7 Sg & 
18 : [next_sP] "m" (next->thread.sp), \ 
19 [next ip] "m" (next->thread.ip), 
20 ep \ 


21 } while (0) 


在 每 次 进程 切换 时 ， 调 度 函 数 将 准备 切 出 的 进程 的 寄存 器 esp 中 的 值 保 
存在 其 任务 结构 中 ， 见 第 5 行 代码 。 然 后 从 下 一 个 投入 运行 的 进程 的 任务 结 
构 中 恢复 esp， 见 第 6 行 代码 。 除 了 栈 指针 外 ， 程 序 下 一 次 恢复 运行 时 的 地 址 
也 有 一 点 点 复杂 ， 不 仅仅 是 简单 的 保存 eip 中 的 值 ， 有 一 些 复杂 情况 需要 考 
虑 ， 比 如 稍 后 我 们 会 看 到 对 于 新 创建 的 进程 ， 其 恢复 运行 的 地 址 的 设置 。 
所 以 调度 函数 也 将 eip 保 存 到 了 任务 结构 中 ， 第 7 行 代码 就 是 保存 被 切 出 进程 
下 次 恢复 时 的 运行 地 址 。 第 8 行 代码 和 第 10 行 的 jmp， 以 及 函数 switch_to 
最 后 的 ret 指 令 联手 将 投入 运行 的 进程 的 地 址 ， 即 next- > thread.ip， 恢 复 到 寄 
存 器 eip 中 。 


除了 eip、esp 外 ， 安 switch_to 将 其 他 寄存 器 如 eflags、ebp 等 保存 到 了 进 
程 内 核 栈 中 。 


每 次 中 断 时 ，CPU 会 从 TSS 段 中 取出 当前 进程 的 内 核 栈 的 栈 指针 ， 
此 ， 当 发 生 任务 切换 时 ，TSS 段 中 的 esp0 的 值 也 要 更 新 为 下 一 个 投入 运行 任 
务 的 内 核 栈 的 栈 指针 。 在 宏 switch_ to 中 ， 即 上 面 第 10 行 代码 处 ， 调 用 函数 
_ switch_to 的 目的 殉 是 设置 TSS 段 中 的 esp0: 


linux-3.7.4/arch/x86/kernel/process 32.c: 


motrace funcgraph struct task struot * ‘switeh to(,., .) 


{ 

load sp0(tss, next),; 
} 
linux-3.7.4/arch/x86/include/asm/processor.h: 


static inline void load sp0(...) 


{ 
} 


static inline void native load sp0(...) 


l 


native load sp0(tss, thread); 


tss->x86 tss.sp0 = thread->sp0; 


综 上 ， 进 程 在 内 核 中 的 切换 过 程 如 独 5-27 所 示 ， 其 中 next 才 示 即 将 投入 
运行 的 任务 ，prev 表 示 当 前 任务 ， 但 和 是 马 上 将 被 切 出 。 被 切 出 进程 下 一 次 恢 
复 运 行 时 的 地 址 并 不 一 定 是 吏 定 当前 指令 指针 中 的 地 址 ， 所 以 独 中 eip 使 用 
了 虚线 ， 其 表达 的 意图 束 古 进程 恢复 运行 时 的 地 址 也 保存 在 了 进程 的 任务 
结构 中 。 


CPU 


task struct (prev) 


thread struct 


-二 ”User Space 二 
Process Address Space 


图 5-27 内 核 中 的 进程 切换 


3. 伪 造 现场 


我 们 先 来 看 看 内 核 是 如 何 伪造 内 核 现场 的 。 其 实 伪造 内 核 现场 只 需要 
伪造 三 个 关键 的 地 方 ; 进程 恢复 运行 时 的 地 址 ， 即 eip; 进程 的 内 核 栈 的 栈 
指针 ， 这 个 无 需 解 释 了 ， 进 程 当然 需要 知道 目前 的 栈 顶 在 哪里 ， 最 后 还 要 
准备 内 核 栈 的 栈 确 ， 为 了 日 后 在 进程 返回 到 用 户 空 间 后 ， 发 生 中 断 时 ， 
CPU 可 以 找到 内 核 栈 ， 从 内 核 栈 的 栈 接 开始 保存 用 户 现 场 。 


根据 前 面 的 讨论 ， 如 图 5-27， 在 调度 器 调度 下 一 个 进程 投入 运行 时 ， 即 
宏 switch_to 中 ， 将 从 下 一 个 投入 运行 的 进程 的 任务 结构 的 thread_struct 中 加 


载 sp 到 寄存 器 esp; 加 载 ip 到 寄存 如 eip; 并 在 这 个 安 调 用 的 函数 switch_to 
中 ， 将 TSS 段 中 的 sp0 指 网 thread_struct 中 的 sp0。 因 此 ， 要 伪造 这 三 个 数据 ， 
只 需 设 置 任 务 结构 中 的 结构 体 thread_struct 中 下 面 几 个 值 即 可 : 


linux-3.7.4/arch/x86/include/asm/processor.h: 
struct thread struct { 


unsigned long sp0; 


unsigned long sp; 
unsigned long Lp 


i 


进程 的 任务 结构 在 复制 进程 时 创建 ， 因 此 ， 这 几 个 数据 在 复制 进程 时 
伪造 是 再 合适 不 过 了 。 复 制 进程 时 ， 与 结构 体 thread_struct 相 关 的 复制 函数 
为 copy_thread， 其 代码 如 下 : 


linux-3.7.4/arch/x86/kernel/process 32.c: 


01 int copy thread(..., struct task struct *p; struct pt regs *regs) 
02 { 

03 struct pt regs *childregs = task pt regs (p); 

04 i 

05 p->thread.sp = (unsigned long) childregs; 

06 p->thread.sp0 = (unsigned long) (childregs+1); 

07 

08 if (unlikely(!regs)) { 

09 Be 

10 p->thread.ip = (unsigned long) ret from kernel thread; 
41 

12 } 

了 pe 

14 p->thread.ip = (unsigned long) ret from fork; 

5 


16 } 


先 来 看 一 下 结构 体 pt_regs， 这 个 结构 体 就 是 为 了 解释 内 核 栈 底部 保存 
的 进程 的 用 户 现场 而 设计 的 ， 其 中 的 字段 完全 按照 压 栈 的 各 个 寄存 器 的 顺 
序 设 计 。 第 3 行 代码 中 的 宏 task_pt_regs 就 是 获取 内 核 栈 中 pt_regs 的 ， 并 使 用 
childregs 指 向 这 个 区 域 。 


显然 ， 第 5 行 代码 是 在 伪造 栈 指针 。 第 6 行 代 码 是 在 为 TSS 段 伪造 内 核 栈 
的 栈 底 。 但 是 这 两 个 变量 的 值 可 能 让 人 有 些 困惑 ， 我 们 通过 图 5-28 来 直观 展 


I 


TSS sp0 > 所 childregs + 1 
user Space | 
state ptregs 
esp — > | 一 一 -一 -一 一 一 一- 一] 一 childregs 


task struct i 


stack > 


kernel mode stack 
图 5-28 进程 内 核 栈 


根据 图 5-28 可 见 ，childregs 是 进程 在 内 核 态 运行 时 使 用 的 内 核 栈 的 栈 
底 。childregs+1 是 在 childregs 的 基础 上 ， 向 地 址 增 大 方向 偏 移 一 个 pt_regs 的 
大 小 。 也 就 是 说 ， 从 childregs 到 childregs+1 正 是 给 伪造 用 户 现场 预 留 的 空 
间 。 


函数 copy_thread 中 的 第 10 行 和 第 14 行 都 是 在 为 新 复制 的 进程 仿造 返回 
时 的 运行 地 址 。 只 不 过 第 10 行 是 针对 内 核 线程 的 ， 从 进程 0 复制 进程 就 属于 
这 种 情况 。 画 数 ret_from_kernel_thread 与 ret_from_fork 唯 一 的 不 同 是 ， 
ret_from_kernel _thread 在 返回 到 用 户 空 间 前 ， 其 将 执行 一 个 函数 ， 然 后 才 恢 
复 进 程 的 用 户 现场 ， 具 体 如 下 : 


linux-3.7.4/arch/x86/kernel/entry 32.S: 
ENTRY (ret from kernel thread) 
call *PT EBX (%esp) 


ENDPROC (ret from kernel thread) 


AN 显 从 ;这 个 值 是 一 个 
函数 地 址 。 那 么 ， 这 个 新 复制 的 进程 ， 在 返回 用 户 空 间 之 前 到 底 执行 了 一 
个 什么 函数 呢 ? 在 函数 copy_thread 仿 造 eip 时 ， 其 实 已 经 设置 了 寄存 器 ebx 的 
值 : 


linux-3.7.4/arch/x86/kernel/process 32.c: 

01 int copy _ thread (unsigned long clone flags, unsigned long sp, 

02 unsigned long arg, struct task struct *p, struct pt regs *regs) 
03 { 

04 struct pt regs *childregs = task pt _ regs (p); 

06 if (unlikely(!regs)) { 


08 p->thread.ip = (unsigned long) ret from kernel thread; 


10 childregs->bx = sp; /* function */ 


寄存 器 ebx 中 保存 的 是 辑 数 copy_thread 的 第 2 个 参数 sp， 我 们 再 来 看 看 这 


个 参数 是 什么 : 


linux-3.7.4/kernel/fork.c: 


static struct task struct *copy process (unsigned long clone flags, 
unsigned long stack start, ...) 


retval = copy_ thread(clone flags, stack start, ...); 


} 


long do fork(unsigned long clone flags, 
unsigned long stack start, ...) 
{ 


p = copy_ process (clone flags, stack start, ...); 


我 们 来 回顾 一 下 进程 1 的 创建 过 程 : 


linux-3.7.4/init/main.c: 


static noinline void init refok rest init (void) 


{ 


kernel thread (kernel init, NULL, CLONE FS | CLONE SIGHRAND) ; 
} 
linux-3.7.4/kernel/fork.c 
pid t kernel thread(int (*fn) (void *), void *arg, ...) 
{ 


return do fork (flags|CLONE VM|CLONE UNTRACED, 
(unsigned long)fn, NULL, ...); 


可 见 ， 寄 存 絮 ebx 中 保存 的 是 函数 kernel_init 的 地 址 。 而 恰恰 是 
kernel_init， 开 启 了 创建 进程 的 第 二 阶段 ， 即 exec 的 过 程 。 也 就 是 说 ， 在 复 


制 进程 后 ， 在 返回 用 户 空 间 之 前 ， 内 核 开 启 了 exec 过 程 ， 加 载 可 执行 程序 。 
与 我 们 编写 普通 程序 时 ， 在 复制 之 后 ， 使 用 exec 执 行 新 的 程序 异曲同工 。 


显然 ， 在 加 载 可 执行 程序 之 后 ， 是 一 个 伪造 用 户 现场 的 合理 时 机 。 
为 ， 只 有 这 个 时 候 ， 才 知道 新 执行 的 程序 的 入 口 地 址 ， 也 就 是 进程 切换 到 
用 户 空 间 后 的 执行 地 址 。 而 且 ， 也 只 有 在 进程 的 地 址 空间 建立 好 之 后 ， 才 
能 知道 进程 的 用 户 栈 的 位 置 。 相 关 代 码 如 下 : 


linux-3.7.4/fs/binfmt elf.c: 


static: i1nt load elf binarytstruct linux binprm *bprmy wos 


人 


start thread(regs, elf entry, bprm->p); 


在 加 载 了 可 执行 文件 后 ， 函 数 load_elf_binary 确 定 了 进程 在 用 户 空间 的 
入 口 elf_entry， 也 确定 了 进程 的 用 户 栈 所 在 的 位 置 bprm->p， 然 后 调用 函数 
start_thread 伪 造 进 程 的 用 户 空 间 的 现场 ， 代 码 如 下 : 


linux-3.7.4/arch/x86/kernel/process 32.c: 


void start thread(struct pt regs *regs, unsigned long new ip， 
unsigned long new sp) 
{ 


set_ user gs (regs, 0); 


regs->fs = 0; 

regs->ds = _ USER DS; 
regs->es = __USER DS; 
regs->ss = USER DS; 


regs->C8 = USER CS; 
regs->ip = new ip; 
regs->sp = Dew sp; 


在 函数 start_thread 中 ， 各 个 段 寄 存 堪 均 被 设置 为 了 用 户 空间 的 段 ， 进 程 
的 栈 也 指向 了 用 户 空 间 的 栈 。 于 是 ， 在 ret_from_kernel_ thread 最 后 ， 从 进程 
的 内 核 栈 恢复 用 户 现场 时 ， 进 程 被 彻底 打 回 原形 ， 从 天 上 掉 到 了 人 间 ， 进 
程 又 作 回 了 凡人 ， 在 用 户 空间 从 入 口 地 址 elf_entry 处 开始 执行 。 


5.4.3” 按 需 载 入 指令 和 数据 


在 建立 进程 的 地 址 空间 时 ， 我 们 看 到 ， 内 核 仅 仅 是 将 地 址 映射 进来 ， 
没有 加 载 任何 实际 指令 和 数据 到 内 存 中 。 这 主要 还 是 出 于 效率 的 考虑 ， 一 
个 进程 的 所 有 指令 和 数据 并 不 一 定 全 部 要 用 到 ， 比 如 某 些 处 理 错误 的 代 
码 。 某 些 错 误 可 能 根本 不 会 发 生 ， 如 采 也 将 这 些 错 误 代 码 加 载 进 内 存 ， 驶 
是 白白 占据 内 存 资 源 。 而 且 特别 对 于 某 些 大 型 程序 ， 如 果 启 动 时 全 部 加 载 
进 内 存 ， 也 会 使 启动 时 间 延 长 ， 让 用 户 难 以 忍受 。 所 以 ， 在 实际 需要 这 些 
旨 令 和 数据 时 ， 内 核 才 会 通过 缺 页 中 断 处 理 函 数 将 指令 和 数据 从 文件 按 需 
加 载 进 内 存 。 这 一 玉 ， 我 们 束 来 具体 讨论 这 一 过 程 。 


1. 获 取 引 起 缺 页 异常 的 地 址 


IA32 架 构 的 缺 页 中 断 的 处 理 函 数 do_page_fault 调 用 函数 do_page_fault 
处 理 缺 页 中 断 ， 相 天 代码 如 下 : 


linux-3.7.4/arch/x86/mm/fault.c: 


01 static void kprobes do page fault (struct pt regs *regs, ...) 


v2 :{ 

03 

04 address = read cr2(); 

05 i 

06 vma = find vma (mm, address); 

07 if (unlikely(!vma)) { 

08 bad arealregs, error code, address); 

09 return; 

10 } 

1 入 if (likely (vma->vm start <= address)) 

12 goto good area; 

13 if (unlikely(! (vma->vm flags & VM GROWSDOWN))) { 
14 bad arealregs, error code, address); 

1 return; 

16 } 

17 Ds 

18 if (unlikely (expand stack (vma, address))) { 
19 bad arealregs, error code, address); 

2 得 return; 

21 } 

必 22 和 

23 good area: 

24 sR 

25 fault = handle mm fault (mm, vma, address, flags); 
26 

2 


在 发 生 缺 页 中 断 时 ， 寄 存 絮 CR2 中 你 存 的 是 引起 缺 页 中 断 的 线性 地 址 。 

因此 ， 第 4 行 代 码 首先 到 寄存 器 CR2 中 读 取 线性 地 址 。 然 后 ， 画 数 

_ do_page_fault 检 查 这 个 地 址 的 合法 性 ， 判 断 条 件 束 是 这 个 地 址 是 否 在 某 个 
vma 的 范围 内 。 注 意 这 里 的 函数 find_vma， 它 从 了 映 映 进 程 地 址 空间 底部 的 
vm_area_struct 对 和 象 开始 裔 历 ， 当 找到 第 一 个 结束 地 址 恰好 要 大 于 这 个 异常 
地 址 、 但 是 却 是 最 接近 这 个 异常 地 址 的 vm_area_struct 对 象 时 ， 就 将 这 个 对 
象 返 回 。 如 果 找 不 到 这 样 一 个 vm_area_struct 对 象 ， 那 么 就 说 明 这 个 地 址 是 
非法 的 ， 内 核 将 向 进程 发 送 SIGSEGV 信 号 ， 这 是 程序 运行 时 出 现 segment 
fault 的 原因 之 一 ， 见 代码 第 6~10 行 。 


如 果 找 到 了 一 个 vm_area_struct 对 象 ， 并 有 旦 引起 异常 的 这 个 地 址 也 大 于 
这 个 vm_area_struct 对 象 的 起 始 地 址 ， 那 么 就 说 明 这 个 地 址 恰好 在 其 说 盖 的 
范围 内 ， 直 接 跳 转 到 标号 good_area 处 ， 见 代码 第 11~12 行 。 


但 是 ， 假 如 引起 异常 的 这 个 地 址 小 于 vm_area_struct 对 象 的 起 始 地 址 ， 
那 也 不 能 一 棍子 打 死 ， 我 们 还 要 给 它 一 次 机 会 。 在 前 面 讨 论 栈 段 的 创建 
时 ， 我 们 已 经 看 到 ， 内 核 初始 只 为 进程 分 配 了 一 个 页 面 大 小 的 空间 ， 
此 ， 其 完全 有 可 能 是 一 次 压 栈 操作 ， 但 是 栈 空间 尚未 映 冉 具 体 的 物理 地 
址 ， 如 图 5-29 所 示 。 


kernel space 


vm end 


vm area struct | 一 push 


Process address space 
图 5-29 栈 异 常 


那么 如 何 判断 这 个 vm_area_struct 对 象 是 否 是 代码 的 栈 段 呢 ? 那 束 要 看 
其 成 员 vm_flags 中 是 否 设置 了 VM_GROWSDOWN 这 个 标志 。 如 果 这 个 


vm_area_struct 对 象 是 栈 段 ， 则 首先 对 栈 进行 扩展 。 代 码 第 13~21 行 就 是 处 理 
这 种 特殊 情况 的 。 


2. 更 新 页 表 


在 复制 子 进程 时 ， 子 进程 也 需要 复制 或 者 共享 父 进程 的 页 表 。 如 果 没 
有 页 表 ， 了 于 进程 寸步 难 行 ， 指 令 或 者 数据 的 地 址 根本 没有 办 法 映射 到 物理 
地 址 ， 更 不 用 提 从 物理 内 存 读 取 指 令 了 。 当 子 进程 替换 (exec) 为 一 个 新 的 
程序 时 ， 无 论 子 进程 是 共享 或 者 复制 了 父 进 程 的 页 表 ， 子 进程 都 需要 创建 
新 的 页 表 。 创 建 页 表 的 函数 如 下 : 


linux-3.7.4/arch/x86/mm/pgtable.c: 


pgd t *pgd alloc(struct mm struct *mm) 


pgd = (pgd t *) get free page (PGALLOC GFP); 
pgd ctor (mm, pgd); 
} 


static void pgd ctor(struct mm struct *mm, pgd t *pgd) 
if (PAGETABLE LEVELS == 2 || ...) { 
clone pgd range (pgd + KERNEL PGD BOUNDARY, 
swapper pg dir + KERNEL PGD BOUNDARY, 
KERNEL PGD PTRS); 


函数 pgd_alloc 申 请 了 一 个 物理 内 存 页面 ， 然 后 调用 函数 pgd_ctor 将 存储 
在 swapper_pg_dir 处 的 页 目录 中 的 映射 内 核 空间 的 页 目录 项 复制 过 来 。 我 们 


看 到 ， 这 里 没有 复制 映射 用 户 空 间 的 页 目录 项 ， 而 且 也 不 需要 复制 ， 因 为 
用 户 空间 需要 映射 到 一 个 新 的 程序 。 于 是 ， 页 目录 中 映射 用 户 空 间 的 这 些 
页 目录 项 的 目 然 为 室 ， 更 不 用 提 那 些 还 没有 影 儿 的 页 表 了 。 当 访问 地 址 落 
在 这 些 空 的 页 目录 项 映射 范围 内 时 ， 目 然 束 引发 了 缺 页 异 第 。 那 么 在 缺 页 
异 第 处 理 函 数 中 ， 目 然 束 需 要 分 配 页 面 、 分 配 页 表 、 更 新 页 目录 、 更 新 页 


表 项 等 。 


为 了 可 以 映射 更 大 的 地 址 空间 ，Linux 中 使 用 多 个 级 别 的 页 面 映 射 。 
此 ， 我 们 先 来 理解 一 下 内 核 中 页 表 的 管理 。 比 如 缺 页 异常 处 理 函 数 调用 的 
函数 handle_mm_fault， 代 码 如 下 : 


linux-3.7.4/mm/memory.c: 


int handle mm fault(...) 
pgd t+t *pgd; 
Bud. t *pud; 
pmd 七 *pmd ; 
Si 


pgd 


= pgd offset (mm, address); 
pud = pud alloc (mm, pgd, address); 
iTf {PBUd) 


return VM FAULT OOM; 
pmd = pmd alloc (mm, pud, address),; 


从 上 述 代 码 中 我 们 看 到 了 pgd、pud、pmd 和 pte。 读 者 应 该 可 以 猜 出 
来 ， 内 核 使 用 了 4 级 页 表 机 制 。 但 是 这 4 级 页 表 是 如 何 与 物理 上 的 页 表 结 合 


的 呢 ? 我 们 以 没有 开启 PAE 的 IA32 架 构 为 例 ， 来 探讨 这 一 过 程 。 


对 于 没有 局 用 PAE 的 IA32， 其 映射 的 地 址 空间 为 4GB， 所 以 理论 上 内 核 
使 用 与 IA32 物 理 上 相同 的 2 级 页 表 就 足够 了 。 但 是 为 了 代码 的 一 致 性 ， 内 核 
依然 保留 了 pud 和 pmd 等 概念 。 只 不 过 通过 一 些 巧妙 的 定义 ， 绕 过 了 中 间 的 
pud 和 pmd。 当 配置 内 核 时 ， 如 果 示 开启 支持 IA32 的 PAE 特 性 ， 内 核实 质 上 
将 使 用 2 级 页 表 。 内 核 使 用 了 文件 pgtable-nopud.h 和 pgtable-nopmd.h 中 有 关 
pud 和 pmd 的 一 些 定 义 : 


linux-3.7.4/arch/x86/include/asm/pgtable types.h: 

#if PAGETABLE LEVELS > 3 

Wa 

#include <asm-generic/pgtable-nopud.h> 

ei 

#if PAGETABLE LEVELS > 2 

Helse 

#include <asm-generic/pgtable-nopmd.h> 

en 

从 文件 名 字 我 们 就 已 经 看 出 了 内 核 的 意图 ， 束 是 要 屏蔽 pud 和 pmd 层 。 

下 面 ， 我 们 就 结合 这 两 个 文件 中 的 定义 ， 来 看 看 内 核 是 如 何 绕 过 pud 和 pmd 
的 。 以 函数 handle_ mm_fault 中 使 用 的 函数 pud_alloc 为 例 : 


linux-3.7.4/include/linux/mm.h: 


static inline pud t *pud alloc(struct mm struct *mm, pgd 七 *pgd, 


unsigned long address) 
{ 


return (unlikely(pgd none(*pgd)) && pud allocl(mm, pgd, 
address))? NULL: pud offset (pgd, address); 


在 文件 pgtable-nopud.h 中 函数 pgd_none 的 定义 为 : 


linux-3.7.4/include/asm-generic/pgtable-nopud.h: 


static inline int pgd none (pgd t pgd) { return 0; } 


也 就 是 说 ， 辑 数 pgd_none 永 远 返 回 9， 那 么 pud_alloc 中 的 函数 
_ pud_alloc 就 不 需要 执行 了 ， 而 且 pud_alloc 返 回 的 值 就 是 函数 pud_offset 的 
返回 值 ， 这 个 函数 当然 也 对 应 的 是 文件 pgtable-nopudh 中 的 实现 : 


linux-3.7.4/include/asm-generic/pgtable-nopud.h: 


static inline pud t * pud offset (pgd t * pgd, unsigned long address) 


{ 
} 


return (Pud 上 *)pgd; 


看 到 函数 pud_offset 的 实现 ， 我 想 读 者 一 定 会 悦 然 大 悟 。 显 然 ，pud 就 是 
pgd。pmd_alloc 亦 是 如 此 处 理 的 ， 读 者 可 以 仿照 上 面 的 方法 目 行 查看 。 也 束 
是 说 在 使 用 了 2 级 页 表 的 情况 下 ，pud 和 pmd 就 像 透明 的 空气 ， 根 本 不 存在 ， 
内 核 绕 了 一 个 圈 后 又 回 到 原点 。 虽 然 代码 中 还 有 所 谓 的 pud、pmd 等 ， 但 是 
所 谓 的 pud 和 pmd 都 是 pgd。 


读者 亦 不 要 被 诸如 pgd_t、pud_t、pmd_t 等 这 些 封 闭 的 数据 类 型 所 迷 
惑 ， 说 日 了 ， 它 们 束 是 一 些 表 项 中 的 值 。 再 直 日 一 点 ， 束 是 一 个 整数 ， 或 
者 至 多 是 个 整数 的 数组 而 已 。 这 里 之 所 以 使 用 了 一 个 结构 体 将 这 些 整数 夫 
痛 起 来 ， 束 是 为 了 屏蔽 这 些 表 项 的 细节 ， 避 人 免 日 后 的 改动 影响 更 多 的 代 
码 。 


了 解 了 内 核 的 页 表 管理 机 制 后 ， 下 面 我 们 整 来 具体 看 一 下 函数 


handle mm _ fault。 


linux-3.7.4/mm/memory.c: 


01 int handle mm fault (struct mm struct *mm, struct vm area struct 


02 *vma, unsigned long address, unsigned int flags) 
03 { 

04 pgd t *pgd; 

05 pud 七 *pud; 

06 pmd 七 *pmad; 

07 Be BG pees 

08 人 

09 pgd = pgd offset (mm, address); 

10 pud = pud alloc(mm, pgd, address); 

a if (!pud) 

12 return VM FAULT OOM; 

13 pmd = pmd alloc(mm, pud, address); 

14 A 

15 if (unlikely (pmd none(*pmd)) && _ pte alloc(mm, vma, pmd, 
16 address)) 
ny 

18 } 


函数 handle_ mm_fault 首 移 确定 引起 异 闻 的 地 址 是 由 哪个 页 目录 项 映射 
的 ， 见 第 9 行 代码 。 


在 确定 了 页 目录 项 pgd 后 ， 如 前 面 讨论 ， 我 们 可 以 无 视 第 10~13 行 关于 
pud 和 pmd 的 部 分 。 后 面 的 pud 和 pmd 都 是 pgd 。 


确定 了 页 目录 项 后 ， 第 15 行 代码 融 要 判断 页 目录 项 是 否 为 空 。 如 宁 页 
目录 项 为 空 ， 显 然 还 要 分 配 页 表 。 前 面 我 们 已 经 看 到 ， 对 于 一 个 新 加 载 的 
程序 ， 页 目录 表 中 映射 用 户 空 间 的 页 目录 项 是 空 的 。 所 以 pmd_none 的 值 一 
定 是 True。 进 而 继续 执行 函数 _pte_alloc 分 配 页 表 ， 人 代码 如 下 : 


linux-3.7.4/mm/memory.c: 


int _ pte alloc(struct mm struct *mm, struct vm area struct *vma, 
pmd t *pmd, unsigned long address) 
{ 
pgtable t new = pte alloc one(mm, address) ; 
if (likely(pmd none(*pmd))) { /* Has another populated it ? */ 
mm->nr ptes+t+; 
pmd populate (mm, pmd, new); 
new = NULL,; 
} else if (unlikely(pmd trans splitting (*pmd))) 


函数 __pte_alloc 首 先 调 用 pte_alloc_one 分 配 了 一 个 物理 页 面 承 载 页 表 ， 
然后 调用 函数 pmd_populate， 将 这 个 页 表 的 地 址 填充 进 页 目录 表 中 对 应 的 表 
项 。 这 里 ， 对 于 使 用 2 级 页 表 的 情况 ，pmd 表 就 是 页 目录 表 ， 所 以 函数 
pmd_populate 也 不 是 在 填充 什么 pmd 表 ， 而 是 填充 页 目录 表 。 


3. 从 文件 载 入 指令 和 数据 


页 表 准 备 就 绪 后 ，handle_mm_fault 最 后 准备 载 入 指令 和 数据 了 : 


linux-3.7.4/mm/memory.c: 


int handle mm fault(...) 


{ 
pte = pte offset map(pmd, address); 


return handle pte fault (mm, vma, address, pte, pmd, flags); 


handle_mm_fault 首 先 调 用 函数 pte_offset_map 取 得 引起 异常 的 地 址 在 页 
表 中 的 页 表 项 。 训 无 疑问 ， 这 个 页 表 项 pte 也 是 空 的 。 然 后 handle_mm_fault 
调用 函数 handle_pte_fault 从 文件 载 入 指令 和 数据 : 


linux-3.7.4/mm/memory.c: 


01 int handle pte fault (struct mm struct *mm, 


02 struct vm area struct *vma, unsigned long address, 
03 pte t *pte, pmd t *pmd, unsigned int flags) 
04 { 

05 了 ER entryy 

06 spinlock t *ptl; 

07 

08 entry = *pte; 

09 if (!pte present (entry)) { 

10 if (pte none(entry)) { 

El if (vma->vm ops) { 

2 if (likely(vma->vm ops->fault)) 
13 return do linear fault (mm, vma, address, 
14 pte, pmd, flags, entry); 
15 } 

16 return do anonymous page(...); 
1 } 

18 if (Pte 五 le (entzy) ) 

2] return do nonlinear fault (sd 3 
20 return do swap page(...):; 

Bh } 

22 

23 } 


handle_pte_fault 首 先 调 用 pte_present 检 查 这 个 pte 是 否 存 在 ， 见 第 9 行 代 
码 。 


如 采 不 存在 ， 那 么 可 能 有 两 种 情况 : 第 一 种 情况 是 页 面 征 首次 访问 ， 
也 融 是 这 个 页 表 项 是 彻底 的 空 的 ， 而 不 仅仅 是 没有 置 位 present， 在 这 种 情 
况 下 ， 需 要 建立 页 面 映 射 ， 见 代码 第 10~17 行 ;第 二 种 情况 是 页 面 映射 已 经 
建立 了 ， 只 不 过 是 目前 交换 出 内 存 了 ， 即 代码 第 18~20 行 处 理 的 情况 。 我 们 
只 讨论 第 一 种 情况 。 


对 于 第 一 种 情况 ， 也 存在 两 种 情况 : 一 种 钙 如 采 vm_area_struct 对 象 中 
的 成 员 vm_ops 存 在 ， 并 且 vm_ops 中 提供 了 函数 fault， 那 么 说 明 段 古 映 冉 到 
文件 的 ， 见 代码 第 11~15 行 ;否则 是 匿名 映射 。 这 里 我 们 只 讨论 典型 的 从 文 
件 加 载 的 情况 ， 代 码 如 下 : 


linux-3.7.4/mm/memory.c: 
static int do linear fault(struct mm struct *mm, struct 
vm area struct *vma, unsigned long address, 


pte t *page table, pmd 七 *pmd, ...) 


pgoff t pgoff = (((address & PAGE MASK) 
- Vvma->vm start) >> PAGE SHIFT) + vma->vm pgoff; 


pte unmap (page table); 
return do fault(mm, vma, address, pmd, pgoff, flags, 


orig pte); 


} 


do_linear_fault 文 个 函数 非 看 似 简单 ， 仅 一 条 计算 指令 ， 计 算 了 变量 
pgoff 的 值 ， 然 后 就 将 后 续 处 理 丢 给 了 函数 _do_fault°。 但 是 小 计算 大 智慧 ， 
不 要 小 看 这 条 计算 指令 ， 它 计算 出 的 pgoff 是 从 文件 载 入 指令 和 数据 的 关 
键 。 


我 们 知道 ， 每 次 从 文件 加 载 指令 或 者 数据 时 ， 都 是 以 页 面 为 单位 的 ， 
所 以 我 们 可 以 将 文件 想象 为 多 个 连续 的 页 面 。 那 么 如 何 确 定 引 起 异 第 的 这 
个 地 址 对 应 于 文件 中 的 哪个 页 面 呢 ? 


事实 上 ， 当 从 文件 中 将 段 映 射 到 进程 地 址 空间 时 ， 创 建 的 段 的 
vm_area_struct 对 象 中 的 成 员 vm_pgoff 已 经 记录 了 上 段 在 文件 中 的 偏 移 ， 而 且 
是 以 页 为 单位 的 。 一 个 段 可 以 占据 一 个 或 者 多 个 页 面 。 


当 发 生 缺 页 异 第 时， 虽然 不 能 确定 引起 异常 的 地 址 是 在 文件 中 的 哪 一 
个 页 面 ， 但 是 可 以 计算 出 这 个 地 址 相对 于 段 的 起 始 地 址 的 差 值 。 将 这 个 差 
值 转换 为 以 页 为 单位 ， 再 加 上 段 在 文件 中 的 偏 移 ， 即 可 确定 这 个 地 址 在 文 
件 中 的 哪个 页 面 上 。 


我 们 用 图 5-30 来 更 直观 地 表示 一 下 这 个 过 程 。 图 5-30 表 示 数 据 段 及 其 相 
应 的 vm_area_struct 对 象 ， 其 中 使 用 虚线 框 起 来 的 页 是 数据 段 所 映 映 的 范 
围 。 


Process address space 


Page frame | 
vm_pgoff 


ld vm area struct | | 
一 一 一 一 一 一 一 ' |Page frame|! 
[入 vm_end | 9 | 
Data Segment vm_pgoff : 


lv 


> < 


(addr_x' - vm _start)/4k 


: Page framel™ 
| addrx | :|_addrx | 0 
addr x 有 | | (addr x' - vm_start)/4k 
、 vm file 
四 Page frame 
< struct file 


(addr x' - vm start)/4k 4 


Y 
(addr_x' = addr_x 4KB aligned) |address space 


图 5-30 异常 地 址 到 页 面 的 计算 


我 们 以 下 面 程序 中 变量 g_a 为 例 ， 具 体 体 验 一 下 这 个 偏 移 的 计算 过 程 。 


nb ga = L100 


void mainl() 


人 
} 


为 了 更 具有 代表 性 ， 我 们 使 用 静态 链接 ， 这 样 编译 出 的 可 执行 文件 尺 
才 大 一 操 ， 页 面 俩 移 可 以 多 一 点 。 


root@baisheng:~/demo# gcc -static -o hello main.c 


(1) 段 在 文件 的 偏 移 (vm_pgoff) 


因为 变量 g_a 在 数据 段 ， 所 以 我 们 看 看 数据 段 在 可 执行 文件 中 的 偏 移 : 


root@baisheng:~/demo# readelf -1 hello 


Program Headers: 


Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg 
LOAD 0x000000 0x08048000 0x08048000 0xa517d 0xa517Q R E 
LOAD 0x0a5fa4 0x080eefa4 0x080eefa4 0O0x0O0cdc 0x023c8 RW 


我 们 看 到 数据 段 在 文件 中 的 偏 移 是 0x0a5fa4， 按 照 页 面 对 齐 后 ， 数 据 段 
应 该 从 文件 中 偏 移 0x0a5000 处 开始 映射 。 而 0x0a5000/0x1000=165， 也 就 是 
说 ， 数 据 段 映射 的 文件 的 起 始 位 置 是 第 165 个 页 。 


(2) 引起 异常 的 地 址 在 段 内 的 偏 移 


一 个 段 可 能 会 映射 到 文件 中 的 多 个 页 ， 所 以 我 们 还 要 计算 具体 的 地 址 
在 段 内 的 偏 移 (以 页 为 单位 ) 。 


root@baisheng:~/demo# readelf -s hello | grep ga 
2184: 080ef068 4 OBJECT GLOBAL DEFAULT 24 ga 


变量 g_a 的 地 址 为 0x080ef068。 因 为 映射 是 以 页 为 单位 的 ， 所 以 这 个 地 
址 应 该 包含 在 从 0x080ef000 到 0x080f0000 一 个 页 面 中 。 因 此 ， 使 用 地 址 
0x080ef000 与 段 的 起 始 地 址 0x080ee000 做 差 ， 从 而 得 出 这 个 地 址 所 在 页 在 段 
内 的 偏 移 : 


0x080ef000 - 0x080ee000 = 0x1000 


即 偏 移 一 个 页 。 也 束 古 说 ， 在 段 在 文件 中 的 偏 移 的 基础 上 ， 再 偏 移 一 
个 页 就 可 以 了 ， 即 载 入 文件 第 166 (165+1) 页 的 数据 到 内 存 。 


根据 上 面 的 讨论 可 见 ，do_linear_fault 这 个 函数 的 主要 目的 正如 同 其 名 
字 一 样 ， 是 处 理 这 个 线性 的 缺 页 异常 地 址 ， 将 其 从 线性 地 址 转换 为 相应 的 
页 单元 。 侦 移 这 个 参数 准备 好 了 ， 我 们 继续 往 下 看 _do_fault 。 


linux-3.7.4/mm/memory.c: 


static int _do fault(struct mm struct *mm, struct vm area struct 
*vma, unsigned long address, pmd t *pmd, pgoff t pgoff, ...) 


struek Vm Faultb vue 


vmf .virtual address = (void _ user *) (address & PAGE MASK); 
vmf .pgoff = pgoff; 


二 = vma->vm ops->fault (vma, &vmf); 

AE = Vvmf .page; 

Dg Ge = pte offset map lock(mm, pmd, address, &pt]1); 
| entry = mk ptel(page, vma->vm page prot); 


set pte at (mm, address, page table, entry); 


函数 do_fault 调 用 具体 文件 系统 中 的 fault 函 数 ， 将 所 需 的 文件 数据 读 
入 到 内 存 。 至 于 读 入 哪个 页 面 ， 当 然 要 使 用 刚刚 计算 的 pgoff 了 。 以 ext4 文 件 
系统 为 例 ， 其 为 vma 提 供 的 vm_operations_struct 如 下 : 


linux-3.7.4/fs/ext4/file.c: 


static const struct vm operations struct ext4 file vm ops = { 
.fault = filemap fault, 
.page mkwrite = ext4 page mkwrite, 
.remap_pages = generic file remap pages, 


ext4 文 件 系统 中 的 身 emap_fault 将 指定 偏 移 处 的 页 面 读 入 内 存 ， 其 中 参 
数 vmf 中 的 page 束 是 指向 从 文件 载 入 的 页 面 。 


载 入 页 面 后 ， 还 有 最 后 一 步 要 做 : 更 新 页 表 项 。 函 数 _do_fault 氏 定 页 
表 中 映 喘 这 个 页 面 的 页 表 项 ， 然 后 调用 函数 mk_pte 创 建 页 表 项 的 值 ， 
调用 set_pte_at 将 页 表 项 的 值 填 充 到 页 表 中 对 应 的 页 表 项 。 


5.4.4， 加载 动态 链接 需 


在 现代 操作 系统 中 ， 绝 大 部 分 程序 都 是 动态 链接 的 。 对 于 动态 链接 的 
程序 ， 除 了 加 载 可 执行 程序 外 ， 其 依赖 的 动态 库 也 要 加 载 。 对 于 动态 链接 
的 程序 和 库 ， 编 译 时 并 不 能 确定 引用 的 外 部 符号 的 地 址 ， 因 此 在 加 载 后 ， 


还 要 进行 符号 重 定位 。 


为 了 降低 内 核 的 复杂 度 ， 上 述 工 作 并 没有 包含 在 内 核 中 ， 而 是 转移 到 
了 用 户 空间 ， 由 用 户 空 间 的 程序 来 完成 这 个 过 程 。 这 个 程序 被 称 为 动态 加 
载 /链接 器 (dynamic linker/loader) ， 一 般 也 将 其 简称 为 动态 链接 器 。 后 续 
行文 中 ， 几 是 没有 使 用 “动态 ”二 字 修 饰 的 链接 右 ， 均 指 编 译 时 的 链接 絮 。 
内 核 只 负责 将 动态 链接 右 加 载 到 内 存 ， 其 他 的 都 区 由 动态 链接 郁 去 处 理 。 


为 了 更 大 的 灵活 性 ， 内 核 不 会 假定 系统 中 使 用 动态 链接 右 ， 而 是 由 可 
执行 程序 主动 告诉 内 核 谁 是 动态 链接 器 。 当 编译 一 个 可 执行 程序 时 ， 链 接 
絮 将 创建 一 个 类 型 为 "INTERP" 的 段 ， 这 个 段 非 党 简单 ， 束 是 包 仿 一 个 字符 


串 ， 这 个 字符 串 就 是 动态 链接 器 的 名 字 ， 以 可 执行 程序 hello 为 例 : 


root@baisheng:~/demo# readelf -1 hello 


Program Headers: 


Type Offset VirtAddr PhysAddr FileSiz MemSiz 
PHDR 0x000034 0x08048034 0x08048034 0x00120 0x00120 
INTERP Ox000154 Ox08048154 Ox08048154 0x00013 0x00013 


[Requesting program interpreter: /lib/ld-linux.so.2] 


由 上 可 见 ， 类 型 为 "INTERP" 的 段 就 是 一 个 19 (0x13) 个 字符 长 的 字 
串 "Mib/1d-linux.so.2"， 正 是 动态 链接 器 。 


当 内 核 加 载 可 执行 程序 时 ， 其 将 检查 可 执行 程序 的 Program Header 
Table 中 是 否 包含 有 类 型 为 "TINTERP" 的 段 ， 代 码 如 下 : 


linux-3,7.4/f8/binfmt elf .ce 


Statlio nt Load elf ‘binary (Btruct Tinux binprm, “hprm, oa 


{ 


struct file *interpreter = NULL; /* to shut gcc up */ 
char * elf interpreter = NULL; 


for (i = 0; i < loc->elf ex.e phnum; i++) { 
if (elf ppnt->p type == PT INTERP) { 


elf interpreter = kmalloc{(elf ppnt->p. filesz; 
GFP_ KERNEL); 


retval = kernel read (bprm->file, elf ppnt->p_offset, 
elf interpreter, elf ppnt->p filesz); 


interpreter = open exec(elf interpreter); 


} 


elf ppnt++; 


如 果 有 INTERP 的 段 ， 那 么 说 明 这 个 ELF 文 件 是 一 个 动态 链接 的 可 执行 
程序 。Linux 中 动态 链接 器 以 动态 库 的 方式 实现 ， 于 是 内 核 需要 将 动态 链接 
器 这 个 动态 库 加 载 到 进程 的 地 址 空间 ， 代 码 如 下 : 


linux-3.7.4/fs/binfmt elf.c: 


static int load elf binary (struct linux binprm *bprm, ;..) 


{ 
if (elf interpreter) { 


elf entry =; load elf interp(&loc=-Sinterp; elf ex; 
interpreter, &interp map addr, load bias); 
if (!IS ERR((void *)elf entry)) { 


interp load addr = elf entry; 
Lt ‘entry ss TO -SLiterp. Sif Sie ES 


} 


start thread (regs, elf entry, bprm->p); 


加 载 动态 链接 器 与 加 载 可 执行 程序 的 过 程 基 本 完全 相同 ， 函 数 
load_elf_interp 束 是 一 个 徐 化 版 的 load_elf_binary， 这 里 我 们 不 再 效 述 。 完 成 
动态 链接 器 加 载 后， 需要 跳 转 到 动态 链接 器 的 入 口 继续 执行 。 那 么 ， 如 何 
确定 动态 链接 器 的 入 口 地 址 呢 ? 动态 链接 器 的 ELE 头 中 将 记录 一 个 入 口 地 
址 : 

root@baisheng:/vita/sysroot/lib# readelf -h 1d-2.15.so | 


grep -i entry 
Entry point address: 0x1050 


难道 编译 时 链接 器 计算 错 了 ? 0x1050 不 太 像 进程 地 址 空间 的 虚拟 地 
址 。 没 错 ，0x1050 是 虚拟 地 址 ， 只 不 过 是 因为 在 编译 时 不 能 确定 动态 库 的 
加 载 地 址 ， 所 以 动态 库 中 地 址 分 配 从 0 开始 ， 见 下 面 动态 库 的 Program 
Header Table: 


root@baisheng:/vita/sysroot/lib# readelf -1 ld-2.15.so 


Program Headers: 


Type Offset VirtAddr PhysAddr FileSiz MemSiz 
LOAD 0x000000 0x00000000 0x00000000 0xlf47c Oxlf47c 
LOAD Ox0lfcc0 0x00020cc0 0x00020cc0 0x00bpb8 0x00c78 


函数 load_elf_interp 返 回 的 是 动态 链接 器 在 进程 地 址 空间 中 的 映射 的 基 
址 ， 所 以 在 这 个 基 址 加 上 入 口 地 址 0x1050 后 才 是 动态 链接 器 的 入 口 的 真正 
的 运行 时 地 址 。 计 算 好 动态 链接 右 的 入 口 地 址 后 ， 内 核 调 用 函数 
start_thread， 伪 造 了 用 户 现 场 。 在 进程 切换 到 用 户 空 间 时 ， 将 跳 转 到 动态 链 
接 万 的 入 口 处 开始 执行 。 


我 们 看 看 动态 链接 器 入 口 地 址 对 应 的 符号 : 


root@baisheng:/vita/sysroot/lib# readelf -s 1d-2.15.so | grep 1050 
443: 00001050 0 NOTYPE LOCAL DEFAULT 10 start 


可 见 ， 动 态 链接 右 的 入 口 是 符 号 _start: 


glibc-2.15/sysdeps/i386/dl-machine.h: 


StarteN\nN 
# Note that dl start gets the parameter jn %eax.\n\ 
moVv] Sesp, Seax\n\ 
all GREEN 
_dl1 start user:\n\ 
# Save the user entry point address in S$%edi.\n\ 
movl] %Seax, Sedi\n\ 


jmp *%Sedi\n\ 


函数 _start 调 用 _dl_start 在 进行 一 些 自身 的 必要 的 准备 工作 。 其 中 最 重要 
Ne 


的 一 点 是 动态 链接 着 也 是 一 个 动态 库 ， 其 在 进程 地 址 空间 中 的 地 址 也 是 加 


载 时 才 确 定 的 ， 因 此 动态 链接 器 也 需要 重 定位 ， 我 们 将 在 5.4.8 节 讨论 这 一 
过 程 。 


然后 ，_dl_start 调 用 函数 dlL_main 加 载 动 态 库 以 及 重 定位 工作 。 其 中 ， 加 
载 动态 库 的 过 程 在 5.4.5 节 讨论 ， 重 定位 动态 库 的 过 程 在 5.4.6 和 讨论 ， 有 天 
重 定位 可 执行 程序 的 部 分 将 在 5.4.7 玫 讨论 。 


在 完成 加 载 及 重 定位 后 ， 函 数 _dl_start 将 返回 可 执行 程序 的 入 口 地 址 。 
因此 ， 汇 编 指令 从 寄存 器 eax 中 取出 可 执行 程序 的 入 口 地 址 ， 并 临时 保存 到 
寄存 器 edi。 在 这 段 程序 的 最 后 ， 通 过 指令 "jmp*%edi" 跳 转 到 可 执行 程序 的 
入 口 处 开始 执行 可 执行 程序 。 


男 外 ， 我 们 再 留意 一 下 上 面 代码 中 的 标号 _dl_start_user。 从 这 个 标号 处 
开始 ， 到 最 后 跳 转 到 可 执行 程序 的 入 口 前 ， 动 态 链接 器 将 调用 动态 库 相 关 
的 一 些 初 始 化 函数 。 前 面 在 第 2 章 中 最 后 在 动态 库 的 初始 化 部 分 添加 的 那个 
函数 ， 吏 是 在 这 里 执行 的 。 


我 们 以 一 个 具体 的 例子 看 看 动态 链接 郁 在 进程 地 址 空间 中 映射 的 情 
况 : 


root@baisheng:~# cat /proc/self/maps 
08048000-08053000 r-xp 00000000 08:01 261656 /bin/cat 


b7736000-b7756000 r-xp 00000000 08:01 523936 
/lib/i386-linux-gnu/ld-2.15.so 

b7756000=-b7757000 r==p 0001f000 08:01 523936 
/lib/i386-linux-gnu/1d-2.15.so 

b7757000-b7758000 rw-p 00020000 08:01 523936 
/lib/i386-linux-gnu/ld-2.15.so 


可 见 ， 对 于 这 个 进程 ， 动 态 链接 器 被 映射 到 进程 地 址 空间 从 
0xb7736000 开 始 的 地 方 ， 这 个 就 是 我 们 前 面 提 到 的 动态 库 在 进程 地 址 空间 
中 映射 的 基 址 。 其 中 0xb7736000~0xb7756000 这 个 段 的 权限 是 "rx"， 显 然 这 
个 段 应 该 是 代码 段 和 一 些 只 读 的 数据 ，0xb7756000~0xb7757000 和 
0xb7757000~0xb7758000 都 对 应 的 是 数据 段 。 但 是 为 什么 数据 段 被 划分 为 两 
个 段 ? 其 实 不 只 是 动态 链接 器 如 此 ， 包 括 其 他 动态 库 和 动态 链接 的 可 执行 
程序 都 是 如 此 ， 具 体 原因 我 们 将 在 5.4.9 节 讨论 。 


5.4.5 ”加 载 动 态 库 


加 载 动态 库 前 ， 首 先 需 要 知道 这 个 可 执行 程序 依赖 的 动态 库 ， 当 然 也 
包括 这 些 动态 库 依 赖 的 动态 库 ， 因 此 ， 这 十 一 个 递归 的 过 程 。 那 么 动态 链 
接 器 是 如 何 知 道 这 些 依赖 的 动态 库 呢 ? 动态 链接 各 不 是 一 个 人 在 战斗 ， 在 
编译 时 ， 和 链接 器 已 经 为 动态 链接 做 了 很 多 铺 束 ， 其 中 之 一 束 古 在 ELF 文 件 中 
创建 了 一 个 段 ".dynamic"， 保 存 的 全 部 是 与 动态 链接 相关 的 信息 。 


我 们 观察 一 下 可 执行 程序 hello 中 的 段 ".dynamic'': 


root@baisheng:~/demo# readelf -d hello 


Dynamic section at offset OxfOc contains 25 entries: 


Tag Type Name/Value 

0x00000001 (NEEDED) Shared library: [libf].so] 

0x00000001 (NEEDED) Shared library: [libc.s6.6] 
0x00000003 (PLTGOT) 0x804a000 

0x00000002 (PLTRELSZ) 40 (bytes) 

0x00000014 (PLTREL) REL 

0x00000017 (JMPREL) Ox8048430 

0x00000011 (REL) Ox8048420 


段 ".dynamic" 中 记录 了 多 组 与 动态 库 有 关 的 信息 ， 每 一 组 信息 都 使 用 如 
下 格式 保存 : 


林业 工本 三 2 5 六 全 


typedef struct 


ELf32_ Sword d tag; /* Dynamic entry type */ 


union 
{ 
Elf32 Word qd val; /* Integer value */ 
ElES2 AddE dd pr; /* Address value */ 
} d_un; 


} Elf32_Dyn; 


可 见 ， 每 组 信息 使 用 的 是 tag/value 的 形式 保存 ， 只 不 过 value 有 的 是 个 整 
数值 ， 有 的 是 地 址 而 已 。 


其 中 类 型 (Type) 为 "NEEDED" 的 项 记录 的 就 是 可 执行 程序 依赖 的 动态 
库 。 可 以 看 到 ，hello 依 赖 动态 库 libc.so.6 和 libf1.so。 


动态 链接 器 设计 了 一 个 数据 结构 来 代表 每 个 加 载 到 内 存 的 动态 库 ( 包 
括 可 执行 程序 ) ， 定 义 如 下 : 


glibc-2.15/include/link.h: 
struct link map 
ElfW(Addr) 1 addr; 
char *] name; 
ElfWw(Dyn) *1 1d; 
struct link map *1 next; *] prev; 


ElfW(Dyn) *] info[DT NUM + DT THISPROCNUM + DT VERSIONTAGNUM 
+ DT EXTRANUM + DT VALNUM + DT ADDRNUM]; 


这 个 数据 结构 中 记录 了 动态 库 重 定位 需要 的 关键 两 项 信息 : 1_addr 和 
1]_1d4。]_addr 记 录 的 是 动态 库 在 进程 地 址 空间 中 映 射 的 基 址 ， 有 了 这 个 参 


照 ， 动 态 链接 絮 才 可 以 修订 符号 的 运行 时 地 址 ;1_1d 指 辣 动 态 库 的 

段 ".dynamic"， 通 过 这 个 参数 ， 动 态 链 接 器 可 以 知道 一 切 与 动态 重 定位 相关 
的 信息 。 为 了 方便 ， 结 构 体 link_map 中 定义 了 一 个 数组 L info， 将 

段 "..dynamic" 中 的 信息 记录 在 这 个 数组 中 ， 就 不 必 每 次 使 用 时 再 去 重新 解 
析 ".dynamic" 了 。 


当 内 核 将 控制 权 转交 给 动态 链接 器 时 ， 链 接 器 首先 为 即将 处 理 的 可 执 
行程 序 创建 一 个 link_map 对 象 ， 在 动态 链接 器 代码 中 将 其 命名 为 
main_map。 然后， 动态 链接 锋 找 到 这 个 可 执行 程序 依赖 的 动态 库 ， 当 然 也 
包括 其 依赖 的 动态 库 也 依赖 的 动态 库 ， 依 次 链接 在 main_map 的 后 面 ， 形 成 
一 个 link_map 对 象 链表 。 动 态 链 接 右 作为 动态 库 依 赖 的 一 个 动态 库 ， 目 然 也 
包含 在 这 个 链表 中 。 沿 着 这 个 链表 ， 动 态 链 接 右 将 动态 库 映 喘 进 进程 地 址 


空间 ， 并 进行 重 定位 。 


函数 dlL_main 调 用 _dl_map_object_deps 加 载 可 执行 程序 依赖 的 所 有 动态 
库 ， 代 码 如 下 : 


glibc-2.15/elf/rtld.c: 


static void dl main (const ElfW(Phdr) *phdr, ...) 


{ 
_d1 map object deps (main map, ...); 


glibc-2.15/elf/dl-deps.c: 


void internal function 
_dl map object deps (struct link map *map, ...) 


{ 


for (runp = known; runp; ) 


{ 


int err = dl catch error (&objname, &errstring, 
&malloced, openaux, &args); 


static void openaux (void *a) 


{ 


args->aux = dl map object (args->map, args->name, ...); 


} 


函数 dL_main 给 函数 _dl_map_object_deps 传 递 了 一 个 参数 main_map， 前 
面 提 到 过 这 个 参数 ， 就 是 可 执行 程序 的 link_map 对 象 。 画 数 
_dl_map_object_deps 所 历 可 执行 程序 依赖 的 所 有 动态 库 ， 对 每 一 个 动态 库 调 

玉 数 _d]_map_object 将 这 些 动态 库 全 部 映 冉 到 进程 的 地 址 空间 ， 代 码 如 
下 : 


glibc-2.15/elf/dl-load.c: 


struct link map * internal function dl map object (...) 


{ 


return dl map object from fd (name, fd, &fb, realname, 
loader, type, mode, &stack end, nsid); 


因为 动态 库 可 能 已 经 被 加 载 到 内 存 了 ， 所 以 _dl_map_object 和 首先 从 已 经 
映射 的 动态 库 中 寻找 。 如 果 没 有 找到 ， 则 调用 函数 _dl_map_object_from_fd 
从 文件 系统 加 载 ， 代 码 如 下 : 


glibc-2.15/elf/dl-load.c: 


struct link map * dl map object from fd (..,.) 


{ 


1->1] map start = (El]fW(Addr)) _ mmap ((void *) mappref, 


maplength, c->prot, MRP COPY |MAP FILE, fd, c->mapoff).; 


1=31 addr = 1->1] map start ~- c-S>mapstart; 


_dl_map_object_from_fd 调 用 了 芳 数 _mmap 了 映射 文件 中 的 段 到 进程 地 址 空 
则 ， 并 将 映射 其 址 记录 到 ]ink_map 中 的 ]_addr。 至 于 函数 mmap， 读 者 应 该 
已 经 隐隐 猜 出 来 了 ， 没 错 ， 这 个 函数 就 是 我 们 编写 应 用 程序 时 使 用 的 C 库 的 
函数 mmap， 只 不 过 这 是 在 C 库 内 部 调用 ， 所 以 函数 名 称 略 有 差别 ， 其 实现 
如 下 : 


glibc-2.15/sysdeps/unix/sysv/linux/i386/mmap.s: 
ENTRY (__mmap) 
movl] S$SYS ify(mmap2), %eax /* System call number in %eax.*/ 


/* Do the system call trap. */ 
ENTER KERNEL 


_mmap 首 和 完 将 系统 调用 号 _NR_mmap2 装 入 寄存 器 eax， 然 后 束 癌 内 核 
请 求 服务 。 这 里 请 求 内 核 服务 时 之 所 以 没有 使 用 0x80 中 断 ， 原 因 是 为 了 在 


支持 快速 系统 调用 (Fast System Call) 指令 sysenter/sysexit 的 CPU 上 使 用 这 
些 比 0x80 中 断 更 优化 的 系统 调用 指令 。 


在 映射 了 程序 段 后 ， 范 数 _d]_map_object_from_fd 调 用 了 函数 _mprotect 
设置 段 的 读 、 写 以 及 可 执行 权限 ，_mprotect 使 用 的 是 内 核 调 用 号 为 


__NR_mprotect 的 服务 。 


我 们 看 到 ， 动 态 链 接 右 并 没有 发 明 什 么 新 的 魔法 ， 它 只 是 使 用 内 核 提 
供 的 系统 调用 将 动态 库 映 射 到 进程 的 地 址 空间 。 也 就 是 说 ， 虽 然 动 态 库 是 
由 动态 链接 套 在 用 户 空间 进程 映射 的 ， 但 是 本 质 上 的 映射 动作 还 是 由 内 核 
完成 的 。 


最 后 ，_dL_map_object_from_fd 将 link_map 中 的 成 员 1_ 1d 指 加 了 
段 ".dynamic" 所 在 的 位 置 : 


glibc-2.15/elf/dl-load.c: 


struct link map * dl map object from fd (const char *name, ...) 


{ 


for (ph = phdr; ph < &phqr [1->1_phnum] ; ++ph) 
Switch (ph->p_type) 


{ 


case PT DYNAMIC: 
1->1 ld = (void *) ph->p vaddr; 


1->1 1d = (ElfW(Dyn) *) ((ElfW(Addr)) 1->1 ld + 1->1 addr); 


函数 _ql_map_object_from_fd 从 Program Header Table 中 取出 类 型 
为 "DYNAMIC" 的 段 的 地 址 ， 然 后 再 加 上 动态 库 的 映射 基 址 。 


最 后 ， 我 们 结合 图 5-31 来 直观 地 看 一 下 多 个 进程 是 如 何 共享 一 个 动态 库 


的 。 
Kernel space Kernel space 
Data Segment COW 
mmap base Stack (read and write) Wr Stack nia Bese 
> < 
_w Data Segment | 和 
Memory Map Data Segment -1 (read only) -| Data Segment Memory Map 
Segment OE BE Segment 
ode Segment ode Segment 
~ | 
Code Segment a 
Heap Heap 


Physical memory 


Process address space A Process address space B 


图 5-31 动态 库 的 映射 


最 初 ， 当 共享 库 映 射 进 内 存 后 ， 代 码 段 和 数据 段 在 物理 内 存 中 分 别 都 
只 有 一 份 副 本 ， 并 且 都 是 只 读 的 ， 进 程 A 和 进程 B 共 享 只 读 的 代码 段 和 数据 
段 。 在 进程 运行 过 程 中 ， 当 任 一 个 进程 试图 修改 数据 段 时 ， 则 内 核 将 为 这 

个 进程 复制 一 份 私 有 的 数据 段 的 副本 ， 而 且 这 个 数据 段 的 权限 被 设置 为 可 

读 写 的 。 这 里 使 用 的 策略 就 是 所 谓 的 写 时 复制 (COW,Copy On Write) 。 但 
征 这 个 复制 动作 不 会 影响 进程 的 地 址 空间 ， 对 进程 是 透明 的 ， 只 是 同一 段 

地 址 通过 页 面 表 映 喘 到 不 同 的 物理 页 面 而 已 。 


5.4.6 ” 重 定 位 动态 库 


动态 库 在 编译 时 ， 链 接 右 并 不 知道 最 后 被 加 载 的 位 置 ， 所 以 在 编译 


时 ， 共 享 库 的 地 址 是 相对 于 0 分 配 的 。 以 动态 库 libf1.so 为 例 : 


root@baisheng:~/demo# readelf -1 libfl.so 


Program Headers: 


Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg 
LOAD Ox000000 0x00000000 0x00000000 0x00658 0x00658 RE 


LOAD Ox000eec 0x00001eec 0x00001eec 0x00138 0x0013c RW 


根据 动态 库 libf1.so 的 Program Header Table， 注 意 列 VirtAddr， 显 然 地 址 
是 从 0 开始 分 配 的 。 因 此 ， 在 映射 到 具体 进程 的 地 址 空间 后 ， 需 要 修订 其 中 
那些 通过 绝对 方式 引用 的 符号 的 地 址 ， 代 码 如 下 : 


glibc-2.15/elf/rtldes 


atatlie vold ql maln saa) 


{ 


/* Now we have all the objects loaded. Relocate them all ...*/ 


unsigned i = main map->] searchlist.r nlist; 
while: (i== ® ©) 


{ 


struct link map *1 = main map->l1 initfini [i]; 


if (1 != &GL(dl1 rtld map)) 


a1 relocate object, (lL: 1-%YL. seopes su) 


函数 dl_main 从 main_map 开 始 ， 调 用 函数 _dl_relocate_object 重 定位 
link_map 链 表 中 的 所 有 动态 库 和 可 执行 程序 


， 顺 序 是 从 后 向 前 。 如 果 有 符号 


重 定义 了 ， 那 么 后 面 发 现 的 符号 的 地 址 将 覆盖 掉 前 面 的 符号 地 址 。 换 句 话 
说 ， 链 接 时 排 在 前 面 的 动态 库 中 的 符号 将 被 优先 使 用 。 男 外 ， 还 有 一 上 后 要 
注意 ， 这 个 列表 中 的 动态 链接 器 将 不 再 需要 重 定位 ， 因 为 其 已 经 在 前 面 上 自 
己 重 定位 好 了 。 


常用 的 重 定 位 方式 有 两 种 : 加 载 时 重 定位 (Load-time relocation) 和 
PIC 方式 。 


加 载 时 重 定 位 与 编译 时 的 重 定位 非常 相似 。 动 态 链 接 右 在 加 载 动态 库 
后 ， 避 历 动态 库 的 重 定位 表 ， 对 于 重 定 位 表 中 的 每 一 项 记录 ， 解 析 这 个 记 
录 中 指明 的 符号 的 地 址 ， 然 后 使 用 解析 到 的 地 址 修订 这 个 记录 中 指定 的 偏 
移 处 ， 当 然 这 个 偏 移 需 要 加 上 动态 库 映 射 的 基 址 。 


但 是 动态 库 是 多 个 进程 共享 的 ， 不 同 的 进程 映射 的 动态 库 的 地 址 不 
同 ， 因 此 ， 如 有 果 茶 个 进程 按照 动态 库 在 目 己 进程 空间 中 映射 的 基 址 修改 了 
动态 库 的 代码 段 ， 那 么 这 个 动态 库 的 显然 束 不 能 被 其 他 进程 所 共享 了 ， 除 
非 所 有 的 进程 映 味 动态 库 的 位 置 相同 ， 但 是 这 又 带 来 太 多 的 限制 和 问题 。 


基于 以 上 原因 ， 开 发 者 们 又 设计 了 另外 一 种 方式 一 -PIC (Position- 
Independent Code) 。PIC 基 于 两 个 关键 的 事实 : 


令 数据 段 是 可 写 的 。 有 既然 代码 段 是 不 能 更 改 的 ， 但 是 数据 段 总 是 可 以 
更 改 的 。 于 是 PIC 把 重 定 位 战场 从 代码 段 转移 到 数据 段 ， 在 数据 段 中 增加 了 
一 个 GOT (GLOBAL OFFSET TABLE) 表 。 在 编译 时 ， 链 接 器 将 所 有 需要 


重 定 位 的 符号 在 这 个 表 中 分 配 一 项 ， 其 中 记录 了 符号 以 及 其 实际 所 在 的 地 
址 。 重 定位 时 ， 动 态 链接 万 只 修改 GOT 表 中 的 值 。 


令 代码 和 数据 的 相对 位 置 不 变 。 在 代码 中 凡是 引用 GOT 表 中 的 符号 ， 
只 需要 找到 GOT 表 的 地 址 ， 再 加 上 变量 在 GOT 表 中 的 偏 移 即 可 。 但 是 ， 如 
此 还 是 没有 避 开 代码 段 被 修改 的 命运 ， 因 为 动态 库 在 进程 地 址 空间 中 的 位 
置 只 有 在 加 载 时 才能 确定 ， 所 以 ，GOT 表 的 地 址 在 加 载 时 也 需要 重 定位 。 
但 是 ， 我 们 也 注意 到 这 样 一 个 事实 : 对 动态 库 来 说 ， 昌 然 其 映射 的 地 址 在 
编译 时 不 确定 ， 但 是 在 映射 到 进程 的 地 址 空间 时 ， 代 码 段 和 数据 段 依然 按 
照 编译 时 分 配 好 的 地 址 上 映射， 也 就 是 说 ， 指 令 和 数据 的 相对 位 置 却 是 固定 
的 。 因 此 ，GOT 表 作为 数据 段 中 的 一 员 ， 代 码 段 中 的 任 一 指令 与 GOT 表 基 
址 之 间 的 偏 移 是 固定 的 ， 在 编译 时 束 可 以 确定 。PIC 恰 恰 是 基于 这 个 事实 ， 
在 代码 中 凡是 访问 GOT 表 的 地 方 ， 都 是 使 用 这 个 固定 的 相对 偏 移 来 引用 
GOT 表 以 及 其 中 的 变量 ， 因 此 ， 代 码 中 引用 GOT 表 的 地 址 不 再 需要 重 定 
位 ， 从 而 避 开 了 代码 段 被 修改 的 问题 。 接 下 来 我 们 结合 具体 的 实例 进一步 


解释 这 个 过 程 。 


1.GOT 表 


显然 ，PIC 技 术 中 ，GOT 表 是 一 个 非常 重要 的 数据 结构 ， 在 继续 深入 探 
讨 前 ， 我 们 先 来 认识 一 下 这 个 数据 结构 ， 如 图 5-32 所 示 。 


func 2 address 


16 
.got.plt func 1 address 
2 
dl runtime resolve 

8 

link map 和 A 
4 | 

.dynamic 


_GLOBAL OFFSET TABLE 
var 1 address , 
var 2 address vy 
.got 


图 5-32 GOT 表 


由 图 5-32 可 见 ， 这 么 大 名 鼎鼎 的 GOT 表 却 如 此 简单 ， 其 就 是 一 个 一 维 
数组 。 对 于 32 位 CPU 来 说 ， 每 个 数组 元 素 就 是 32 位 的 地 址 。GOT 表 分 成 两 
个 部 分 : .got 和 .got.plt。.got 中 存储 的 是 变量 的 地 址 。.got.plt 中 存储 的 是 函数 
的 地 址 。 在 5.4.9 节 中 我 们 将 讨论 GOT 表 一 分 为 二 的 原因 。 


在 编译 时 ， 链 接 器 将 定义 一 个 符号 GLOBAL _OFFSET_ TABLE_ ， 指 
向 .got 和 .got.plt 的 连接 处 ， 凡 是 访问 GOT 表 中 的 地 址 时 ， 都 使 用 基于 这 个 符 
号 的 偏 移 。 比 如 ， 访 问 变量 var 1， 那 么 使 用 : 


_GLOBAL OFFSET TABLE - 4 


访问 函数 func1 则 使 用 : 


_GLOBAL OFFSET TABLE + 12。 


GOT 表 中 除了 记录 变量 和 画 数 的 地 址 外 ， 还 有 另外 三 个 特殊 的 表 项 ， 
我 们 在 图 5-32 中 也 已 经 标 出 ， 它 们 束 古 .got.plt 的 前 三 项 。 其 中 第 1 项 记录 的 
征 动态 库 或 者 可 执行 文件 的 .dynamic 段 的 地 址 ;第 2 项 记录 的 是 代表 动态 库 
或 者 可 执行 文件 的 link_map 对 象 ， 第 3 项 记录 的 是 动态 链接 锋 提 供 的 解析 符 
号 地 址 的 函数 _dl_runtime_resolve 的 地 址 。 我 们 以 动态 库 libf1.so 为 例 ， 看 看 
在 一 个 已 经 编译 好 的 动态 库 中 ， 这 三 项 的 值 : 


root@baisheng:~/demo# readelf -x .got.plt 1lLibfl.so 
Hex dump of section '.got.plt': 


0x00002000 f81le0000 00000000 00000000 36040000 ............ Gs Ei 
0x00002010 46040000 56040000 Rs 


从 地 址 0x2000 处 起 ， 融 是 .got.plt 开 始 的 地 方 。 其 中 使 用 黑体 标识 的 3 个 
32 位 地 址 就 分 别 是 这 三 项 的 值 。 可 见 ， 除 了 第 1 项 被 赋予 了 具体 的 值 外 ， 其 
余 两 项 全 部 是 0°。 原因 是 段 .dynamic 的 地 址 是 编译 时 就 确定 的 。 我 们 查看 动 
态 库 libf1.so 的 段 .dynamic 的 值 : 


root@baisheng:~/demo# readelf -S libfl.so 


Section Headers: 
[Nr] Name Type Addr Off Size 


[18] .dynamic DYNAMIC 0000lef8 000ef8 0000e8 


上 面 ， 使 用 "-x" 显 示 段 .got.plt 的 内 容 时 ， 是 以 little-endian 表 示 的 ， 所 
以 .dynamic 段 的 地 址 "00001ef8" 被 显示 为 "f81e0000"。 


记录 动态 库 信 息 的 link_map 古 在 加 载 后 创建 的 ， 编 译 时 当然 不 知道 这 个 
运行 时 创建 的 对 象 的 地 址 。 同 理 ， 因 为 动态 链接 右 也 古 以 动态 库 的 形式 加 
载 到 进程 地 址 空间 的 ， 其 映射 地 址 也 是 加 载 时 才 确 定 的 ， 所 以 动态 链接 如 
中 的 函数 _dl_runtime_resolve 的 地 址 也 是 在 动态 链接 如 加 载 后 才能 确定 。 
此 ， 与 段 .dynamic 的 地 址 在 编译 时 就 可 确定 不 同 ， 这 两 项 是 由 动态 链接 右 动 
态 填 充 的 ， 代 码 如 下 


glibc-2.15/sysdeps/i386/dl-machine.h: 


static inline int attribute _ ((unused, always inline)) 
elf machine runtime setup (struct link map *]1], ...) 


{ 


Elf32 Addr *got; 
got = (Elf32 Addr *) D PTR (1, 1 info [DT PLTGOT]); 


2 
3 
二 
5 
6 
dn 
8 got[1] = (El]f32 Addr) 1; /*Identify this shared object.*/ 
下 


0 got [2] = (Elf32 Addr) & dl runtime resolve; 


其 中 第 6 行 语句 将 相关 宏 进行 痊 换 后 ， 展 开 如 下 : 
got = (了 LE32 Addr *) 1=>2L info[DT PLTIGOT] Qun aa ptr’; 


前 面 ， 讨 论 结构 体 link_map 时 ， 我 们 提 到 过 ， 这 个 结构 体 中 的 数组 
1_info 就 是 为 了 方便 存储 段 .dynamic 的 信息 的 。 因 此 ， 这 条 语句 的 目的 驶 是 
从 段 .dynamic 中 取得 GOT 表 的 基地 址 ， 也 就 是 got.plt 的 基 址 。 


接 下 来 的 第 8 行 和 第 10 行 语句 的 目的 是 在 获得 了 .got.plt 的 基 址 之 后 ， 分 
别 设 置 其 中 第 2 项 和 第 3 项 的 值 。 很 明显 ， 一 个 是 代表 动态 库 的 ljink_map 对 
象 ， 另 外 一 个 就 是 函数 _d]_runtime_resolve 的 地 址 。 


读者 这 里 了 解 GOT 表 中 这 特殊 的 三 项 束 可 以 了 ， 更 具体 的 我 们 后 面 会 
讨论 。 其 中 第 1 项 主要 是 动态 链接 器 重 定位 目 己 时 使 用 ， 我 们 将 在 5.4.8 节 讨 
论 ;， 第 2 项 和 第 3 项 主要 是 用 在 函数 的 延迟 绑 定 中 使 用 ， 我 们 在 5.4.6 世 中 讨 


论 。 


2. 重 定位 变量 


变量 的 重 定位 在 动态 库 加 载 时 进行 ， 注 意 不 要 将 这 里 的 加 载 时 与 前 面 
等 指 的 “加 载 时 重 定位 ? 混 清 ， 这 里 指 的 是 使 用 PIC 扩 术 在 加 载 时 进行 的 变量 
重 定 位 的 过 程 。 我 们 分 别 从 代码 中 引用 变量 以 及 动态 链接 右 修 订 GOT 表 两 
个 角度 来 讨论 PIC 中 的 变量 重 定位 。 


(1) 代码 中 引用 变量 


我 们 以 库 libf1 中 的 函数 fool_func 引 用 库 libf2 中 的 符号 foo2 为 例 ， 有 具体 看 
一 下 PIC 中 的 变量 重 定位 。 我 们 反 汇 编 动 态 库 libf1.so， 其 中 引用 全 局 变量 
foo2 的 反 汇 编 代 人 码 片 段 如 下 : 


root@baisheng:~/demo# objdump -d 1Libfl.so 


0000057b < x86.get pc thunk .bx>: 


57b: 93 让 包 没入 mov (Sesp) ,Sebx 
57e: 33 ret 
STES 90 nop 


00000580 <fool func>: 


S80 5.5 push Sebp 
581; 89 e5 mov Sesp, sebp 
5835 53 push Sebx 
584: 83 ec 14 sub $0Ox14,%esp 
S89 写本 有司 往生 泪 仿 泪 二 Gall 57b 
< X86.get pc thunk.bx> 
58c : 81 c3 74 la 00 00 add $0xla74, Sebx 
592; SI B83 ea EE£ Ef£ 和 EEE mOV -0x18 (和 当 ebXx) ,Seax 
598 : 8b 00 mOV (Seax) ,Seax 


1) 获取 下 一 条 指令 的 运行 时 地 址 。 注 意 偏 移 0x587 处 的 指令 ， 其 调用 
了 偏 移 0x57b 处 的 函数 _、x86.get_pc_thunk.cx。 在 调用 这 个 函数 时 ，call 指 令 
会 将 下 一 条 指令 的 地 址 0x58c 压 入 到 栈 中 。 而 在 进入 函数 
_X86.get_pc_thunk.cx 后 ， 其 将 栈 项 的 值 取出 到 寄存 器 ebx 中 ， 然 后 返回 。 显 
然 ， 调 用 这 个 函数 的 目的 就 是 取得 下 一 条 指令 的 运行 时 地 址 。 这 里 之 所 以 
这 么 做 ， 是 因为 x86 指 令 集中 没有 提供 获取 指令 指针 值 的 指令 ， 不 得 以 才 采 
用 的 一 个 小 技巧 。 


2) 计算 GOT 表 的 运行 时 地 址 。 现 在 ， 下 一 条 指令 的 绝对 地 址 保存 在 寄 
存 右 ebx 中 ， 而 下 一 条 指令 与 GOT 之 则 的 偏 移 义 是 固定 的 ， 因 此 寄存 侨 ebx 
加 上 这 个 固定 的 偏 移 后 ， 残 确定 了 GOT 表 在 运行 时 所 在 的 地 址 。 


编译 时 ， 链 接 器 定义 了 一 个 变量 GLOBAL _ OFFSET_TABLE 代表 GOT 
表 的 基 址 ， 库 libf1 中 该 符号 地 址 如 下 : 


root@baisheng:~/demo# readelf -s 1Libfl.so 


Symbol table '.symtab' contains 58 entries: 
Num: Value Size Type Bind Vis Ndx Name 


42: 00002000 0 OBJECT LOCAL DEFAULT 20 GLOBAL OFFSET TABLE 


因此 ， 库 libf1 中 偏 移 0x58c 处 的 指令 到 GOT 表 所 在 位 置 的 差 为 : 0x2000- 
0x58c=0x1a74， 这 就 是 地 址 0x58c 处 的 值 0x1a74 的 由 来 。 也 就 是 襄 ， 这 个 
0x1a74 就 是 指令 与 GOT 表 之 间 的 那个 固定 偏 移 。 


3) 计算 符号 foo2 在 GOT 表 中 的 偏 移 。 取 得 了 GOT 表 的 绝对 地 址 后 ， 如 
要 访问 变量 foo2， 还 要 加 上 变量 foo2 在 GOT 表 中 的 偏 移 。 那 这 个 偏 移 是 多 少 
呢 ? 我 们 看 看 动态 库 libf1 的 重 定位 表 : 


root@baisheng:~/demo# readelf -r 1Libfl.so 


Relocation section '.rel.dyn' at offset 0x38c contains 11 entries: 
Offset Info Type Sym.Value Sym. Name 


00001fe8 00000206 R 386 GLOB DAT 00000000 foo2 


根据 重 定位 表 可 见 ， 符 号 foo2 在 偏 移 0x00001fe8 处 。 而 GOT 表 基 址 在 
0x2000 处 ， 因 此 ， 根 据 这 两 个 值 之 产 就 可 以 确定 从 号 foo2 在 GOT 表 中 的 偏 
移 : 0x1lfe8-0x2000=-0x18， 也 束 是 说 ， 变 量 foo2 相 对 GOT 表 的 偏 移 
是 -0x18。 根 据 ELF 文 件 中 段 的 布局 : 


root@baisheng:~/demo# readelf -S libfl.so 


Section Headers: 
[Nr] Name Type Addr Off Size 


LE9] saot PROGBITS 00001fe0 000fe0 000020 
BOL wg.p1t PROGBITS 00002000 001000 000018 


可 见 ，GOT 表 的 基 址 是 介 于 .got 和 .got.plt 之 间 的 。 对 于 .got 部 分 来 说 ， 
GOT 表 的 基 址 位 于 .got 部 分 的 底部 ， 这 就 是 偏 移 为 负 的 原因 。 之 所 以 将 GOT 
表 的 基 址 设置 在 .got 和 .got.plt 之 间 ， 并 无 特别 的 目的 ， 这 样 访问 .got.plt 就 是 
正 值 了 。 所 以 ， 我 们 看 到 在 库 libf1 的 地 址 0x592 处 在 ebx 的 基础 上 又 加 了 偏 
移 -0x18 。 


(2) 动态 链接 器 修订 GOT 表 


我 们 还 是 以 库 libf1 中 引用 的 库 libf2 中 的 符号 foo2 为 例 ， 来 看 看 在 加 载 
时 ， 动 态 链接 器 是 如 何 解析 这 个 符号 并 修订 GOT 表 的 。 


1) 获取 动态 库 libf1 的 重 定位 表 。 重 定位 信息 保存 在 重 定位 表 中 ， 
此 ， 动 态 链接 絮 首 先 要 找到 重 定位 表 。 段 .dynamic 中 类 型 为 REL 的 条 目 记 录 
的 瓯 是 重 定位 表 的 位 置 ， 动 态 库 libf1 段 .dynamic 中 记录 的 重 定位 表 如 下 : 


root@baisheng:~/demo# readelf -d Libfl.so 


Dynamic section at offset Oxefc contains 25 entries: 
Tag Type Name/Value 


Ox00000011 (REL) 0x38cCc 


可 见 ， 保 存 重 定位 变量 的 表 位 于 0x38c 处 。 因 此 ， 动 态 链 接 器 按照 如 下 
公式 计算 重 定位 表 的 地 址 : 


link map->l1] addr + 0x38c 


2) 根据 重 定位 表 ， 确 定 需 要 修订 的 位 置 。 确 定 重 定位 表 后 ， 动 态 链接 
需 了 驶 遇 历 重 定位 表 中 的 每 一 条 记录 。 以 libf1.so 中 的 引用 的 全 局 变量 
dummy、foo2 和 foo1 的 重 定位 记录 为 例 : 


root@baisheng:~/demo# readelf -r libfl.so 


Relocation section '.rel.dyn' at offset 0x38c contains 11 entries: 


Offset Tn Type Sym.Value Sym. Name 
00001fe0 00000806 R 386 GLOB DAT 00002020 dummy 
00001fe8 00000206 R 386 GLOB DAT 00000000 foo2 
00001ff8 00000c06 R 386 GLOB DAT 0000201c fool 


其 中 第 一 条 重 定位 记录 表示 需要 使 用 符号 dummy 的 值 修订 下 面 位 置 处 
的 值 : 


link map->l1 addr + 0x1lfte0 


第 二 条 重 定 位 记录 表示 需要 使 用 符号 foo2 的 值 修订 下 面 位 置 处 的 值 : 


link map->] addr + 0xlfe8 


第 三 条 重 定位 记录 表示 需要 使 用 符号 foo1 的 值 修订 下 面 位 置 处 的 值 : 


link map->l1] addr + 0xlff8 


3) 寻找 动态 符号 表 。 需 要 修订 的 位 置 确定 后 ， 那 么 接 下 来 就 需要 解析 
符号 的 值 。 动 态 链接 器 从 link_map 这 个 链表 的 表 头 ， 即 代表 可 执行 程序 的 


main_map 开 始 ， 依 次 在 它们 的 动态 符号 表 中 查找 符号 。 所 以 ， 要 解析 符号 
的 地 址 ， 首 先 要 确定 动态 符号 表 的 地 址 。 以 动态 库 libf2 为 例 ， 动 态 链 接 右 
确定 其 动态 符号 表 的 过 程 如 下 。 


动态 链接 器 根据 代表 库 libf2 的 link_map 中 的 字段 1 1d 找 到 段 .dynamic， 
然后 在 该 段 中 取出 动态 符号 表 的 地 址 : 


root@baisheng:~/demo# readelf -d libf2.so 


Dynamic section at offset OxfOc contains 24 entries: 
于 总 宁 Type Name/Value 


0x00000006 (SYMTAB) Ox178 


段 .dynamic 中 类 型 为 SYMTAB 的 项 记录 的 是 动态 符号 表 的 地 址 。 可 见 ， 


libf2 的 动态 符号 表 的 地 址 是 0x178， 因 此 ， 其 在 运行 时 的 绝对 地 址 使 用 如 下 
公式 计算 : 


link map->1 addr + 0x178 


4) 解析 符号 地 址 。 动 态 链 接 器 找到 了 动态 符号 表 后 ， 进 一 步 在 动态 符 
号 表 中 查找 符号 的 地 址 。 以 全 局 变量 foo2 为 例 ， 动 态 链接 器 将 在 库 libf2 的 动 
太 


仿 符号 表 中 找到 这 个 符号 的 信息 : 


root@baisheng:~/demo# readelf -s libf2.so 


Symbol table '.dynsym' contains 13 entries: 
Num: Value Size Type Bind Vis Ndx Name 


9: 00002018 4 OBJECT GLOBAL DEFAULT 1 入 呈 避 2 


上 上述 动 态 符 号 表 中 符号 的 地 址 是 相对 于 0 的 ， 因 此 需要 加 上 libf2 在 进程 
地 址 空间 中 映射 的 基 址 ， 所 以 符号 foo2 的 运行 时 地 址 征 : 


link map Tibf2=31 ‘addr: + 0x2018 


术 后 ， 动 态 链 接 妖 使 用 上 壕 这 个 地 址 ， 修 订 前 面 确定 的 需要 修订 的 位 


虽 


前 面 是 静态 的 分 析 ， 下 面 我 们 将 这 个 例子 运行 起 来 ， 动 态 地 观察 一 下 
全 局 变量 fo02 的 重 定位 过 程 


root@baisheng:~/demo# gdb ./hello 
(gdb) b main 
Breakpoint 1 at 0x80485cf 
(gdb) r 
Starting program: /root/demo/hello 


Breakpoint 1, 0x080485cf in main () 


我 们 在 另外 一 个 终端 中 查看 动态 库 libf2 在 进程 hello 的 地 址 空间 中 映射 
的 基 址 : 


root@baisheng:~/demo# ps -C hello -o pid= 

2897 

root@baisheng:~/demo# cat /proc/2897/maps 

08048000-08049000 r-xp 00000000 08:01 1054223 /root/demo/hello 


b7e15000-b7e16000 r-xp 00000000 08:01 1054350 /root/demo/libf2.so 


b7fd8000-b7fd9000 r-xp 00000000 08:01 1047105 /root/demo/libfl1.so 


可 见 ， 库 libf1 和 1libf2 在 hello 进 程 的 地 址 空间 中 映射 的 基 址 分 别 是 
0xb7fd8000 和 0xb7e15000。 那 么 libf1 中 需要 修订 的 地 址 是 : 


Oxb7fd8000 + Oxlfe8 = 0xb7fd9fe8 


符号 foo2 的 地 址 是 : 


0xb7e15000 + 0x2018 = 0xb7e17018 


下 面 我 们 使 用 gdb 碍 看 内 存 0xb7fd9fe8 处 的 值 ， 如 果 计 算 正 确 ， 那 么 该 
内 存 处 的 值 应 该 已 经 个 动态 链接 絮 修 订 为 0xb7e17018: 


(gdb) x Oxb7fd9fe8 
Oxb7fd9fe8: Oxb7el17018 


根据 输出 结果 可 见 ， 内 存 0xb7fd9fe8 人 处 输出 的 值 与 我 们 理论 上 计算 的 符 
号 foo2 的 地 址 完全 吻合 。 


综 上 可 知 ， 变 量 foo2 的 重 定 位 过 程 如 图 5-33 所 示 。 


Kernel Space 


| .got 
< 
-RELL0x38c | pdynamic 


Oxb7fd8000 
+0xlfe8 


-< link_ map libfl->| Id 
libf1 


ilfe8/foo? | pe 


Oxb7fd8000 _ | 
+0x38C | link_map libf1->l_addr 

oo | (0xb7fd8000) 
© ; 
NN! 
和 
© | 
o | 
Ce 
©| 
| a 
1 SYMTAB / 0x178 amm 
~ |! a Sp Ee en ea 
| A— link map libf2->| ld 


libf2 | i 
i 0x2018 /foo2 je 


0xb7e15000 
+0x178 link map _libf2->|_addr 


(0xb7e15000) 


Process Address Space for hello 


图 5-33 变量 foo2 的 重 定位 过 程 


不 知道 读者 注意 到 没有 ， 在 例子 中 ， 我 们 在 可 执行 文件 hello 和 动态 库 
libf1 中 分 别 定 义 了 全 局 变量 dummy。 这 不 是 我 们 的 笔 误 ， 而 是 故意 为 之 。 
不 知 读者 想 过 没有 ， 对 于 变量 foo2， 其 定义 在 动态 库 libf2 中 ， 编 译 时 动态 库 
libf1 对 其 一 无 所 知 ， 所 以 在 加 载 时 进行 重 定位 ， 我 们 没有 任何 疑义 。 但 
是 ， 对 于 变量 dummy， 其 在 动态 库 libf1 中 已 经 定义 了 ， 既 然 指 令 和 数据 的 


相对 位 置 生 固 定 的 ， 那 么 为 什么 不 采用 与 寻 址 GOT 表 一 样 的 方法 ， 编 译 时 
就 直接 定义 好 位 置 ， 而 还 是 通过 GOT 表 ， 在 加 载 时 进行 重 定位 呢 ? 


我 们 先 反 过 来 问 读者 一 个 问题 : 动态 库 libf1 中 国 数 fool_func 中 引用 的 
变量 dummy 是 动态 库 libf1 中 定义 的 ， 还 是 可 执行 程序 hello 中 定义 的 ? 答案 
是 后 者 。 对 于 一 个 全 局 符号 ， 包 括 函 数 ， 其 可 能 在 本 地 定义 ， 但 在 其 他 库 
中 、 甚 至 包括 使 用 动态 库 的 可 执行 程序 中 也 可 能 有 定义 。 在 动态 链接 器 解 
析 符 号 时 ， 将 沿 着 以 可 执行 程序 的 link_map 对 象 main_map 开 头 的 这 个 链表 
依次 查找 动态 符号 表 ， 使 用 最 先 找到 的 符号 值 。 如 我 们 的 例子 中 ， 可 执行 
程序 hello 的 动态 符号 表 将 先 于 动态 库 libf1 的 动态 符号 表 被 查找 ， 所 以 ， 库 
libf1 中 的 函数 fool_func 将 使 用 可 执行 程序 hello 中 dummy 的 定义 。 


除 此 之 外 ， 还 有 一 种 所 谓 的 Copy Relocation， 也 要 求 即使 引用 同一 个 动 
态 库 中 定义 的 全 局 变量 ， 也 要 使 用 重 定位 的 方式 ， 我 们 在 5.4.7 节 讨论 这 种 
重 定位 情况 。 


3. 重 定位 函数 


前 面 我们 讨论 了 变量 的 重 定 位 ， 本 小 市 我 们 讨论 函数 的 重 定位 。 理 论 
上 ， 函 数 的 重 定位 使 用 与 变量 相同 的 方法 即 可 。 但 是 ， 因 为 相对 比较 少 的 
全 局 变量 的 引用 ， 函 数 引 用 的 数量 可 能 要 大 得 多 ， 因 此 函数 重 定位 的 时 间 
不 得 不 考虑 。 


事实 上 ， 读 者 回想 一 下 我 们 日 常 开发 的 程序 ， 其 实 很 多 代码 不 一 定 能 
全 部 执行 ， 比 如 有 些 分 文 、 错 误 处 理 等 。 而 且 ， 即 使 可 执行 程序 本 喘 使 用 


的 函数 数量 并 不 大 ， 但 是 可 执行 程序 依赖 的 动态 库 可 能 还 会 引用 其 他 动态 
库 中 的 函数 ， 这 些 动态 库 再 依赖 其 他 的 动态 库 ， 如 此 ， 需 要 重 定位 的 函数 
的 数量 不 容 小 凯 。 更 重要 的 是 ， 可 执行 程序 可 能 根本 就 用 不 到 这 些 动态 库 
中 的 函数 ， 因 此 ， 加 载 时 重 定位 函数 只 会 延长 程序 启动 的 时 间 ， 但 是 重 定 
位 的 某 些 函数 却 可 能 根本 就 用 不 到 。 出 于 以 上 考虑 ，PIC 对 于 函数 的 重 定位 
引入 了 延迟 绑 定 技术 (lazy binding) 。 


也 就 是 说 ， 在 加 载 蛙 ， 动 态 链接 器 不 解析 任何 一 个 需要 重 定位 的 钞 数 
的 地 址 ， 而 是 在 运行 时 真正 调用 时 ， 再 去 重 定位 。 为 此 ， 开 发 者 们 引入 了 
PLT (Procedure Linkage Table) 机 制 。 在 GOT 表 的 巧妙 配合 下 ，PIC 将 函数 
地 址 的 解析 推迟 到 了 运行 时 。 


在 编译 时 ， 链 接 絮 在 代码 段 中 插入 了 一 个 PLT 代 码 片 段 ， 每 个 外 部 函数 
在 PLT 中 都 占据 着 一 人 小段 代码 。 我 们 可 以 将 这 些 片段 看 作 外 部 函数 在 本 地 代 
码 中 的 代理 。 代 码 段 中 所 有 引用 外 部 函数 的 地 方 ， 全 部 指 同 其 相应 的 本 地 
代理 。 其 他 具体 的 事情 束 交 由 本 地 代理 去 处 理 。 


PLT 的 代码 片段 的 逻辑 如 图 5-34 所 示 。 


code 


call funcl@plt « funcl ot = 
call func2@plt ¢ func2 .dynamic 
ES link_map 
> funcl@plt: Eg 
O01 If (! first call) : 5 dl runtime resolve 
站 Oxc(%ebx) 民 addr of func1l 
04 push $0x0 一 一 一 i addr of func2 


05 push Ox4(%ebx)” 
06 jmp *0x8(%ebx) 


> func2@plt. 
07 If (! first call) | /| offset 0 
08 jmp*0x10(%eb /| relocation Entry 
09 else : of func1l 
0a push $0x8 A; 
OA 
j 水 9 [UU CY 
Oc jmp *0x8(%ebx) GF Te 
plt code segment 
.rel.plt 


图 。5-34 PLT 代码 片段 


由 图 5-34 可 见 : 


1) 代码 中 所 有 引用 画 数 如 func1、func2 的 地 方 全 部 替换 为 指向 PLT 中 的 
代码 片段 。 因 为 这 里 使 用 的 是 相对 寻 址 ， 所 以 运行 时 代码 段 无 须 再 进行 任 
何 修订 ， 也 就 是 说 ， 代 码 段 不 需要 重 定位 了 。 保 证 了 代码 段 的 可 读 必 性， 

从 而 在 多 个 进程 间 可 以 共享 。 


2) PLT 中 每 个 函数 的 代码 片段 除了 两 处 数据 外 ， 基 本 完全 相同 。 以 调 
用 函数 func1 为 例 ， 它 的 基本 逻辑 是 : 如果 不 古 第 一 次 调用 func1， 束 说 明 画 
数 funcl 的 地 址 已 经 被 解析 ， 并 且 GOT 表 中 对 应 的 funcl 的 地 址 的 项 也 已 经 被 


正确 修订 了 ， 那 么 直接 跳 转 到 GOT 表 中 对 应 的 项 即 可 ， 也 就 是 说 ， 这 样 就 
直接 跳 转 到 函 数 foo2 的 开头 。 这 里 ， 因 为 GOT 表 的 前 3 项 有 特殊 的 用 途 ， 
所 以 func1 的 地 址 占据 GOT 表 的 第 4 项 。ELF 标 准 规定 ， 在 调用 PLT 中 的 代码 
片段 前 ， 主 调 函 数 需要 将 GOT 表 的 基 址 装载 进 寄存 器 ebx， 所 以 ，PLT 中 凡 
是 访问 got 的 地 方 ， 都 使 用 ebx，*0xc (%ebx) 就 是 GOT 表 中 第 4 项 的 值 ， 即 
函数 funcl 的 地 址 。 读 者 可 以 回顾 一 下 前 面 讨 论 的 重 定位 变量 一 站 ， 那 里 讨 
论 确定 GOT 的 基地 址 时 ， 正 是 将 GOT 表 的 地 址 装 入 了 寄存 器 ebx。 


3) 如 果 是 第 一 次 调用 ， 那 么 将 调用 动态 链接 器 提供 的 函数 
_dl_runtime_resolve 解 析 画 数 foo1 的 地 址 。 这 里 显然 不 能 将 函数 
_dl_runtime_resolve 的 地 址 直接 写 在 PLT 代 码 中 ， 如 果 这 样 的 话 ， 那 么 PLT 也 
需要 重 定 位 这 个 函数 ， 除 非 使 用 前 面 提 到 的 加 载 时 重 定位 ， 但 前 面 已 经 提 
到 了 其 种 种 弊端 。 因 此 ， 动 态 链接 器 在 加 载 库 时 ， 将 函数 
_dl_runtime_resolve 的 地 址 填充 到 动态 库 的 GOT 表 的 第 3 项 ， 而 在 PLT 表 中 ， 
直接 跳 转 到 GOT 表 中 第 3 项 保存 的 地 址 ， 即 *0x8 (%ebx) 。 


WI 


en 


4) 在 跳 转 到 函数 _dl_runtime_resolve 的 地 址 前 ， 有 两 条 push 指 令 ， 它 们 
束 是 为 辑 数 _dl_runtime_resolve 准 备 参数 的 。 在 具体 看 这 两 条 直 指 令 前 ， 我 
们 先 来 看 一 下 修订 GOT 表 中 的 函数 地 址 时 需要 的 信息 : 


4 第 一 个 需要 的 信息 是 当前 重 定位 的 函数 在 重 定位 表 中 的 偏 移 。 根 据 
这 个 偏 移 ，_dlL_runtime_resolve 找 到 相应 的 重 定位 条 目 ， 从 而 确定 需要 解析 
的 符号 的 名 字 ， 以 及 需要 修订 的 位 置 。 对 于 函数 在 重 定 位 表 中 的 侦 移 ， 这 
个 在 编译 时 束 可 以 确定 ， 所 以 我 们 看 到 PLT 中 直接 使 用 了 确定 的 数字 。 如 函 


数 funcl 在 重 定 位 表 中 占据 第 1 个 条 目 ， 那 么 仿 移 束 是 0x0， 这 束 古 让 编 指 
令 "push$0x0" 的 作用 。 而 对 于 函数 foo2， 因 为 其 在 重 定位 表 中 占据 第 
目 ， 所 以 仿 移 束 是 0x8 。 


令 第 二 个 是 需要 个 代表 当前 动态 库 的 link_map 对 象 。 要 获得 重 定位 表 ， 
当然 需要 知道 动态 库 映 射 的 基 址 以 及 段 .dynamic 所 在 的 地 址 ， 而 这 些 信息 记 
录 在 库 的 link_map 对 象 中 。 在 查找 符号 时 ， 其 需要 遍历 可 执行 程序 的 
link_map 链 表 ， 因 此 ， 画 数 _dl_runtime_resolve 要 根据 动态 库 的 link_map 对 象 
找到 link_map 链 表 。 而 link_map 也 是 在 动态 链接 器 加 载 库 时 填充 到 GOT 表 中 
的 ， 它 占据 GOT 表 的 第 2 项 ， 这 就 是 PLT 代 码 中 汇编 语句 "push 0x4 

(%ebx) "的 作用 。 


5) 准备 好 参数 后 ，_d]_runtime_resolve 将 开始 寻找 符号 ， 最 后 修订 GOT 
表 中 的 地 址 。 相 关 代 码 如 下 : 


glibc-2.15/sysdeps/i386/dl-trampoline.s: 

_dl runtime resolve: 
movl] 16(%esp), %edx # Copy args pushed by PLT in register. Note 
movl] 12(%esp), %eax # that ‘fixup' takes its parameters in regs. 
call dl fixup # Call resolver. 
moVvl] %Seax, (%esp) # Store the function address. 
ret $12 # Jump to function address. 


cfi endproc 
.size dl runtime resolve, .- dl runtime resolve 


_d]_runtime_resolve 中 核心 的 是 调用 函数 _dl_fixup 进 行人 符号 解析 ， 并 修 
订 GOT 表 。 这 里 使 用 的 是 寄存 器 传 参 ， 所 以 _dl_runtime_resolve 在 调用 
_dl_fixup 前 ， 将 动态 库 的 link_map 存 储 在 寄存 器 eax 中 ， 作 为 传 给 _dl_fixup 


的 第 1 个 参数 ， 将 重 定位 函数 在 重 定位 表 中 的 偏 移 存 储 在 寄存 器 edx， 作 为 
传 给 _dl_fixup 的 第 2 个 参数 。 


然后 ， 在 _dl_fixup 执 行 完毕 后 ， 会 将 解析 的 画 数 的 地 址 返回 。 这 个 返 
回 值 会 放 在 寄存 大 eax 中 ， 所 以 我 们 看 到 _dl_runtime_resolve 在 _ql_fixup 执 行 
完毕 后 ， 会 将 保存 在 寄存 右 eax 中 的 值 放 到 栈 硕 ， 然 后 调用 ret 指 令 ， 将 这 个 
返回 地 址 弹出 到 指令 指针 之 中 ， 从 而 跳 转 到 解析 后 的 地 址 运行 。 


下面 我 们 再 简要 看 一 下 解析 函数 地 址 的 函数 _d]_fixup: 


glibc-2.15/elf/dl-runtime.c: 


01 #ifndef reloc offset 

02 # define reloc offset reloc arg 

03 # define reloc index reloc arg / sizeof (PLTREL) 

04 #endif 

05 

06 _attribute ((noinline)) ARCH FIXUP ATTRIBUTE 

07 dl fixup ( struct link map * _ unbounded 1, ElfW(Word) reloc arg) 


08 { 

09 const ElfWw(Sym) *const symtab 

10 = (const void *) D PTR (1, 1 info[DT SYMTAB]); 

Ws const char *strtab =: (const void *) D PTR {1, 

12 1 info[DT STRTAB]); 

13 

14 Gonst PLTREL *const reéloc = (const void *) (D PTR (1; 

15 1 info[DT JMPREL]) + reloc offset); 

16 const ElfW(Sym) *sym = &symtab[ELFW(R SYM) (reloc->r info)]; 
L7 void *const rel addr = (void *) (1->1 addr + reloc->r offset); 


18 lookup t result; 

19 DL FIXUP VALUE TYPE value; 

20 yi 

下 result = dl lookup symbol x (strtab + sym->st name, 1, 
天 &sSym,1=:3>1 scope, version, ELF RTYPE CLASS PLT, ...); 
3 六 

24 Value = DL FIXUP MAKE VALUE (result, ...); 

25 i 

26 return elf machine fixup: plt (1, result, reloc, rel, addr., 

27 value); 

28 3} 

2 

30 glibc-2.15/sysdeps/i386/dl-machine.h: 

3 

32 static inline Elf32 Addr 

33 elf machine fixup plt (struct link map *map, lookup 七 t, 


34 const Elf32 Rel *reloc, Elf32 Addr *reloc addr, 
35 Elf32 Addr value) 

36 { 

37 return *reloc addr = value; 

38 } 


先 看 函数 _dql_fixup 的 两 个 参数 ， 第 一 个 参数 ] 就 是 传递 进来 的 动态 库 的 
link_map; 第 2 个 参数 reloc_arg 了 驶 是 重 定 位 表 的 侦 移 ， 根 据 第 2 行 代码 的 安定 
义 可 见 ， 函 数 体 中 使 用 的 变量 reloc_offset 就 是 reloc_arg。 


代码 第 9~12 行 根据 传递 来 的 link_map， 首 先 取 得 动态 库 的 动态 符号 表 ， 
包括 SYMTAB 和 STRTAB 。 


代码 第 14~15 行 根据 传 进来 的 函数 在 重 定位 表 中 的 偏 移 ， 从 重 定 位 表 中 
获取 对 应 的 重 定位 记录 reloc 。 


第 16 行 代码 根据 重 定位 记录 reloc 中 符号 在 动态 符号 表 中 的 索引 ， 从 动 
态 符 号 表 symtab 中 取出 符号 的 名 字 。 


第 17 行 代码 根据 重 定位 记录 reloc 中 的 记录 的 偏 移 ， 加 上 库 映 射 的 基 
址 ， 计 算出 需要 修订 的 位 置 。 当 然 这 个 位 置 对 应 的 是 GOT 表 中 的 某 一 项 。 


代码 第 21~22 行 调用 _dl_lookup_symbol_x 人 遍历 link_map 链 表 ， 查 找 符号 
的 地 址 。 


代码 第 26~27 行 调用 elf_machine_fixup_plt 修 订 GOT 表 中 对 应 的 项 ， 函 数 
elf_machine_fixup_plt 中 就 一 条 代码 ， 如 代码 第 37 行 ， 就 是 给 GOT 表 的 某 一 
项 赋 个 符号 地 址 而 已 。 


理论 上 ， 画 数 的 重 定位 过 程 可 以 束 此 完成 了 。 但 是 ， 上 述 方 法 还 有 些 
瑕 症 : 


人 在 PLT 代 码 片 段 中 ， 和 需要 设计 标志 来 表示 芳 数 是 否 是 第 一 次 调用 。 

令 在 PLT 代 码 片 段 中 ， 编 译 器 的 实现 者 们 不 想 做 那个 多 余 的 if 判 断 ， 即 
函数 是 否 是 第 一 次 调用 的 判断 。 尽 管 这 可 能 只 是 一 次 跳 代 和 一 次 访 存 ， 但 
征 编 译 需 的 实现 着 们 还 是 想 把 它们 节省 下 来 。 


于 是 ， 编 译 器 的 设计 者 们 在 上 述 基 础 上 ， 做 出 了 更 进一步 的 改进 ， 如 
图 5-35 所 示 。 


funcl@plt: 


04 jmp *OQxc(%ebx) 
95-else 

06 push $0x0 楼 
07 “push Ox4(%ebx) 
08 jmp *0x8(%ebx) 
func2@plt: 

0b jmp*0x10(%ebx) 
QE-else pe 

0d push $0x8 


0e push Ox4(%ebx) 
Of jmp *0x8(%ebx) 


plt code segment 


.dynamic 


link_map 


_dl_runtime_resolve 


.got.plt 


图 5-35 ”PLT 代码 片 段 


圳 一 ebx 


4 

_dl runtime _resolve() 
5 
5 用 


我 们 看 到 ，PLT 中 的 代码 片段 不 再 进行 任何 判断 ， 而 十 直接 跳 转 到 GOT 
表 中 用 来 保存 解析 的 函数 的 地 址 的 表 项 。 这 里 面 最 关键 的 一 个 技巧 束 古 图 5- 
35 中 用 黑体 标识 的 GOT 表 中 的 两 项 。 编 译 时 ， 编 译 旭 将 函数 对 应 的 项 的 地 
址 初始 化 为 PLT 代 码 片 段 中 jmp 语 句 的 下 一 条 地 址 。 在 动态 库 加 载 持 ， 动 态 
如 会 在 此 基础 上 ， 青 加 上 动态 库 的 映 冉 的 基 址 。 如 此 ， 当 第 一 次 执行 这 个 
六 数 时 ，jmp 语 句 并 没有 跳 转 到 真正 的 函数 的 地 址 处 ， 而 古 直 接 相 当 于 执行 
PLT 代 码 片 段 中 的 下 一 条 语句 ， 即 压 栈 参数 ， 然 后 调用 _dl]_runtime_resolve 
解析 函数 地 址 ， 使 用 解析 的 符号 的 地 址 修订 GOT 表 中 的 项 ， 然 后 跳 转 到 解 


析 的 画 数 的 地 址 ， 执 行 画 数 。 


这 里 不 知 是 否 有 读者 有 过 这 样 的 设想 ， 程序 加 载 时 ， 将 函数 的 GOT 表 


项 直接 填写 为 函数 _d]_runtime_resolve 的 地 址 ， 是 不 是 更 合理 ? 非 也 ，GOT 


表 一 项 只 有 4 字 节 ， 只 能 保存 一 个 地 址 ， 而 调用 dl_runtime_resolve 之 前 ， 还 
需要 其 他 指令 准备 参数 。 


经 过 第 一 次 调用 后 ，GOT 表 中 的 函数 对 应 的 项 已 经 变 为 真正 的 函数 的 
地 址 ， 下 次 再 次 调用 时 ， 将 直接 跳 转 到 函数 的 地 址 继续 执行 ， 如 图 5-36 所 


外 


funcl@plt: 


04 jmp *0xc(%ebx) < ebx 
Q5else 


06 “push $0x0 


.dynamic 
link map 


07 “push Ox4(%ebx) func1!() 
08 jmp *0x8(%ebx) | 

dl_runtime resolve | ， oe { 
Nnc2G@pie addr of func1 } 
0b jmp *0x10(%ebx) eo me 、| func2() 
QEelse { 


0d push $0x8 
0e push Ox4(%ebx) 
Of jmp *0x8(%ebx) 


.got.plt 


plt code segment 


图 5-36 PLT 代码 片 段 


观察 图 5-36 会 发 现 ，PLT 中 func1@plt 中 的 地 址 为 0x7 和 0x8 处 两 行 的 代 
码 ， 以 及 func2@plt 中 地 址 0xe 和 0xf 处 的 代码 完全 一 样 。 事 实 上 ， 所 有 画 数 
的 PLI 拨 段 的 最 后 两 行 都 完全 相同 。 于 是 ，PLT 将 这 两 行 代码 独立 为 一 个 “ 子 
函数 ”plt0。 进 一 步 改进 后 PLI 的 代码 如 图 5-37 所 示 。 


和 01 push 0x4(%ebx) 
02 jmp *0x8(%ebx) 


funcl@pilt: 

0 I ; 

04 jmp *0xc(%ebx) 
05-else 


06 push $0x0 


func2@plt: 

0 | 

0bp jmp *0x10(%ebx) 
0e-else 


0d push $0x8 


图 。5-37 ”PLT 代码 片段 


下 面 我 们 以 库 libf1 中 的 函数 fool_func 调 用 库 libf2 中 的 函数 foo2_func 为 
例 ， 来 具体 体会 一 下 前 面 的 理论 分 析 。 反 汇编 库 libfoo2， 并 截取 引用 函数 
foo2_func 的 有 关 部 分 : 


root@baisheng:~/demo# objdump -d 1Libfl.so 
Disassembly of section .plt: 

00000420 < cxa finalize@plt-0x10>: 

420: ff b3 04 00 00 00 pushl 0x4 (%ebx) 


426: ff a3 08 00 00 00 jmp * 0X8 (Sebx) 


00000450 <foo2 func@plt>: 


450: ff :a3 14 00 00 00 jmp *x 0X14 (%ebx) 
456 : 68 10 00 00 00 push $0x10 
45b: 9 20 EE ff EE jmp 420 < init+0x24> 


Disassembly of section .text: 


00000460 <deregister tm clones>: 
460: 55 push 要 ebp 


00000580 <fool func>: 


SD3 e8 98 fe ff ff call 450 <foo02 func@plt> 


5b8 : 83 c4 14 add $0x14,%esp 


先 来 看 地 址 0x5b3 处 的 指令 。 汇 编 指令 call 的 操作 数 0xfffffe98 〈 补 码 ) 
对 应 的 原 码 是 -0x168，call 指 令 的 操作 数 是 一 个 相对 寻 址 ， 因 此 -0x168 是 目 
标 地 址 和 下 一 条 指令 的 差 值 。 因 为 下 一 条 指令 的 地 址 是 0x5b8， 所 以 跳 转 的 
目的 地 址 是 : 


Ox5b8 - 0X168 = 0x450 


地 址 0x450 处 正 是 PLT 中 对 应 函数 foo2_func 的 片段 。 我 们 看 到 地 址 0x450 
处 的 汇编 指令 跳 转 到 GOT 表 中 偏 移 为 0x14 处 中 的 值 表示 的 地 址 处 。 那 么 
GOT 表 中 这 个 位 置 处 保存 的 是 什么 呢 ? 我 们 需要 到 记录 函数 重 定位 的 表 


.rel.plt 中 寻找 答案 : 


root@baisheng:~/demo# readelf -r Libfl.so 

Relocation section '.rel.plt' at offset 0x3e4 contains 3 entries: 
Offset LiE 人 SS Type Sym.Value Sym. Name 
0000200c 00000307 R 386 JUMP SLOT 00000000 __Ccxa finalize 


00002010 00000407 R 386 JUMP SLOT 00000000  _ gmon start _ 
00002014 00000607 R 386 JUMP SLOT 00000000 foo02 func 


动态 库 ]libf1 的 GOT 表 的 基 址 为 0x2000， 所 以 偏 移 0x14 处 的 地 址 即 为 
0x2014， 也 就 是 重 定 位 表 中 的 第 3 条 记录 。 可 见 ， 这 条 重 定位 记录 要 求 动态 
链接 器 使 用 符号 foo2_func 的 值 填充 地 址 为 0x2014 处 的 GOT 表 项 。 根 据 前 面 
的 理论 分 析 ， 初 始 时 ， 这 个 地 址 指向 下 一 条 push 指 令 ， 即 地 址 0x456 处 的 指 
令 。 所 以 ， 当 首次 调用 foo2_func 时 ， 地 址 0x450 处 的 指令 跳 转 到 了 地 址 
0x456 人 处。 


地 址 0x456 处 的 指令 压 栈 了 一 个 立即 数 0x10。 根 据 前 面 的 理论 分 析 ， 这 
是 为 符号 解析 函数 _dl_runtime_resolve 压 栈 的 一 个 参数 ， 即 需要 重 定位 的 函 
数 在 重 定 位 表 中 的 偏 移 。 根 据 重 定位 表 中 的 信息 ， 范 数 _d]_runtime_resolve 
就 可 以 找到 与 重 定 位 函数 相关 的 信息 ， 如 重 定位 函数 的 符号 名 称 、 需 要 修 
订 的 位 置 等 。0x10 用 十 进 制 表示 是 16， 也 就 是 从 重 定位 表 .rel.plt 开 始 偏 移 16 
字 方 ， 重 定位 表 中 每 个 条 目 占 据 8 字 广 ， 因 此 偏 移 16 字 广 处 的 第 3 条 重 定位 
记录 正 是 记录 函数 f002-func 的 重 定位 信息 。 


继续 看 下 一 条 指令 ， 即 地 址 0x45b 处 的 指令 。 也 是 一 条 相对 跳 转 指令 ， 
补 码 0Oxffffffc0 的 原 码 是 -0x40， 所 以 跳 转 的 目的 地 址 是 : 


Ox460 — 0X40 = 0X420 


objdump 工 具 虽 然 显 示 地 址 0x420 处 的 函数 的 名 字 是 "__cxa_finalize@plt- 
0x10"， 实 际 上 与 函数 "_cxa_finalize" 没 有 任何 关系 ， 这 里 解析 的 有 一 点 
bug， 忽 略 即 可 。 地 址 0x420 处 就 是 PLT 表 的 第 0 项 。 我 们 看 到 plt0 首 先 将 GOT 
表 中 偏 移 0x4 处 ， 即 GOT 表 第 2 项 的 值 ( 库 libf1 的 link_map) 压 栈 ， 显 然 是 给 
解析 函数 传 参 。 然 后 跳 转 到 GOT 表 的 偏 移 0x8 处 ， 即 第 3 项 ， 也 就 是 解析 画 
数 _dlL_runtime_resolve 的 地 址 处 执行 ， 该 函数 解析 符号 foo2_func， 然 后 使 用 
解析 得 到 的 符号 f002-func 的 运行 时 地 址 修订 GOT 表 中 偏 移 0x14 处 ， 即 第 6 
项 ， 然 后 跳 转 到 函数 foo2_func 执 行 。 


首次 调用 函数 foo2_func 后 ，GOT 表 中 第 6 项 保存 的 就 是 foo2_func 的 地 址 
了 。 以 后 再 次 调用 该 函数 时 ，PLT 中 的 foo2_func@plt 将 不 再 跳 转 到 函数 
_dl_runtime_resolve 处 解析 函数 了 ， 而 是 直接 跳 转 到 函数 foo2_func 处 。 


在 静态 分 析 后 ， 下 面 我 们 再 动态 观察 一 下 函数 foo2_func 的 重 定 位 过 
程 。 


我 们 首先 来 看 一 下 编译 时 库 ]ibf1 的 GOT 表 中 第 6 项 ， 即 偏 移 0x2014 处 ， 
保存 的 内 容 是 什么 ， 前 面 我 们 已 经 讨论 过 了 ， 理 论 上 这 里 应 该 是 
foo2_func@plt 中 push 指 令 的 地 址 : 


root@baisheng:~/demo# readelf -r Libfl.so 


Relocation section '.rel.plt' at offset 0x3e4 contains 3 entries: 
Offset Info Type Sym.Value Sym. Name 


00002014 00000607 R 386 JUMP SLOT 00000000 foo02 func 
root@baisheng:~/demo# objdump -D -j .got.plt Libfl.so 
Disassembly of section .got.plt: 

00002000 < GLOBAL OFFSET TABLE >: 


2014: 56 push Sesi 


2015s% 04 00 add $0Ox0, Sal 


root@baisheng:~/demo# objdump -da -j .plt 1Libfl.so 


00000450 <foo2 func@plt>: 


450: ff a3 14 00 00 00 jmp *0X14 (%ebx) 
456: 68 10 00 00 00 push $0x10 
45Db: &9 ‘eq EE ££ Ef£ jmp 420 < init+0x24> 


注意 上 面 使 用 黑体 标识 的 部 分 ， 编 译 时 偏 移 0x2014 处 的 4 字 节 初始 化 为 
0x0456， 正 是 foo2_func@plt 中 push 指 令 的 地 址 。 


我 们 将 hello 运 行 起 来 ， 观 察 一 下 GOT 表 中 第 6 项 的 变化 情况 : 


root@baisheng:~/demo# gdb ./hello 
(gdb) Bb 二 Col_ fune 

Breakpoint 1 at 0x80484d0 
(gdb) r 

Starting program: /root/demo/hello 


Breakpoint 1, Oxb7fd8584 in fool func () from libfl.so 


我 们 在 另外 一 个 终端 中 查看 库 libf1 在 进程 hello 的 地 址 空间 中 映射 的 基 
址 : 


root@baisheng:~# ps -C hello -o pid= 
3 和 2 
root@baisheng:~# cat /proc/3122/maps 
08048000-08049000 r-xp 00000000 08:01 1054223 /root/demo/hello 


b7fd8000-b7fd9000 r-xp 00000000 08:01 1047105 /root/demo/libfl1.so 


根据 输出 可 见 库 libf1 在 进程 hello 的 地 址 空间 中 映射 基 址 是 0xb7fd8000 。 
虽然 说 函数 foo2_func 的 地 址 是 在 使 用 时 再 去 重 定位 ， 但 是 加 载 时 动态 链接 
器 还 是 要 做 一 个 重 定 位 。 读 者 不 禁 要 问 ， 重 定位 什么 呢 ? 我们 以 GOT 表 的 
第 6 项 ， 即 偏 移 0x2014 处 的 值 为 例 。 在 编译 时 ， 我 们 看 到 链接 器 将 此 处 的 地 
址 填充 为 0x0456， 即 jmp 后 的 push 指 令 的 地 址 。 但 是 不 知 读者 是 否 注意 到 ， 
这 个 地 址 是 相对 于 0 的 地 址 ， 在 加 载 后 ， 当 动态 库 libf1 的 映射 基 址 确定 为 
0xb7fd8000 后 ， 显 然 需要 修订 这 个 地 址 为 : 


Oxb7fd8000 + 0x456 = Oxb7fd8456 


我 们 通过 gdb 看 一 下 实际 的 输出 : 


(gdb) x Oxb7fd8000 + Ox2014 
Oxb7fda014: Oxb7fd8456 


可 见 ，GOT 表 中 的 这 一 项 在 加 载 时 确实 修订 了 。 


在 foo2_func 第 一 次 执行 后 ， 这 个 GOT 表 中 的 地 址 就 应 该 修订 为 
foo2_func 的 地 址 ， 我 们 看 一 下 库 libf2 中 为 foo2_func 分 配 的 地 址 ; 


root@baisheng:~/demo# readelf -s Libf2.so 


Symbol table '.dynsym' contains 13 entries: 
Num: Value Size Type Bind Vis Ndx Name 


8: 00000500 5 FUNC GLOBAL DEFAULT Tl £06002 une 


而 动态 库 libf2 在 进程 hello 的 地 址 空间 中 映射 的 基 址 是 : 


root@baisheng:~/demo# ps -C hello -o pid= 


122 
root@baisheng:~/demo# cat /proc/3122/maps 
08048000-08049000 r-xp 00000000 08:01 1054223 /root/demo/hello 


b7e15000-b7e16000 r-xp 00000000 08:01 1054350 /root/demo/libf2.so 


所 以 ， 符 号 foo2_func 的 运行 时 地 址 是 : 
Oxb7el5000 + 0x500 = 0xb7e15500 


我 们 通过 gdb 来 查看 一 下 foo2_func 执 行 一 次 后 ，GOT 表 中 的 保存 这 个 画 
数 的 地 址 被 修订 成 了 什么 : 
(gdb) n 
Ox080485f4 in main () 


(gdb) x Oxb7fd8000 + 0X2014 
Oxb7fda014: 0xb7el5500 


可 见 ， 在 前 次 调用 后 ，GOT 表 中 的 值 已 经 修订 为 符号 foo2_func 的 运行 
时 地 址 。 


5.4.7 重 定位 可 执行 程序 


可 执行 程序 如 果 引 用 的 是 自身 定义 的 函数 和 变量 ， 这 些 符号 在 编译 时 
束 已 经 确定 ， 不 需要 任何 重 定位 。 即 使 其 他 动态 库 中 也 定义 了 与 可 执行 程 
序 中 相同 的 符号 ， 链 接 器 也 优先 使 用 可 执行 程序 自身 定义 的 函数 和 变量 。 


如 琳 引 用 了 动态 库 中 的 函数 和 全 局 变量 ， 那 么 编译 时 可 执行 程序 根本 
不 知道 这 些 符号 最 终 的 地 址 ， 在 重 定位 了 动态 库 之 后 ， 可 执行 程序 也 需要 
重 定 位 这 些 符号 。 可 执行 程序 的 重 定位 与 共享 库 原 理 基 本 一 致 ， 只 有 一 点 
莽 别 ， 我 们 这 里 简单 讨论 一 下 它们 之 间 的 差别 。 


(1) 重 定 位 引用 的 动态 库 中 的 函数 


我 们 以 hello 中 引用 动态 库 libf1 中 的 函数 fool_func 为 例 ， 来 看 关于 函数 
的 重 定位 。 可 执行 程序 hello 中 调用 fool_func 的 反 汇 编 代 码 如 下 : 
root@baisheng:~/demo# objdump -da hello 


080485cc <main>: 


80485ef: e8 dc fe ff f£f call 80484d0 <fool func@plt> 


可 见 ， 可 执行 程序 也 使 用 了 延迟 绑 定 的 技术 。 再 来 看 看 PLT 部 分 的 代 
码 : 


root@baisheng:~/demo# objdump -d -j .plt hello 


Disassembly of section .plt: 

08048480 <sleep@plt-0x10>: 
8048480: ff 35 04 a0 04 08 pushl 0x804a004 
8048486: ff 25 08 a0 04 08 jmp *Ox804a008 


080484d0 <fool func@plt>: 


80484d0: ff 25 lc a0 04 08 jmp *0X804a01c 
80484d6: 68 20 00 00 00 push $0x20 
80484db: ee9 a0 ff ff ff jmp 8048480 < init+0x28> 


与 动态 库 不 同 ， 可 执行 程序 的 地 址 在 编译 时 就 已 经 分 配 好 了 ， 所 以 ， 
GOT 的 地 址 在 编译 时 就 确定 了 ， 不 必 再 如 动态 那样 在 运行 时 动态 获取 GOT 
表 的 基 址 。 我 们 来 看 看 hello 的 GOT 表 的 基 址 : 


root@baisheng:~/demo# readelf -s hello | grep OFFSET TABLE 
44: 0804a000 0 OBJECT LOCAL DEFAULT 23 GLOBAL OFFSET TABLE 


GOT 表 的 基 址 为 0x0804a000， 所 以 任何 以 GOT 表 基 址 为 参照 的 偏 移 ， 
直接 使 用 这 个 地 址 即 可 。 比 如 访问 GOT 表 中 的 第 3 项 ， 即 函数 
_dl_runtime_resolve 时 ， 直 接 在 此 地 址 上 加 两 个 4 字 节 偏 移 即 可 (因为 
_dl_runtime_resolve 占 据 GOT 表 的 第 3 项 ， 所 以 偏 移 8 字 节 ) : 


Ox0804a000 + Ox4*2 = 0X0804a008 


观察 hello 中 plt0 部 分 ， 即 地 址 0x8048486 处 ， 我 们 看 到 ， 指 令 中 也 确实 
是 这 么 做 的 ，jmp 的 目标 地 址 在 编译 时 就 计算 好 了 ， 束 是 *0x804a008。 


除 GOT 表 的 基 址 固定 外 ， 可 执行 程序 函数 的 重 定位 与 动态 库 中 函数 的 
重 定位 完全 一 致 。 


(2) 重 定位 引用 的 动态 库 中 的 变量 


可 执行 程序 与 动态 库 不 同 ， 一 般 而 言 ， 其 地 址 是 编译 时 分 配 好 的 ， 证 
固定 的 (这 里 我 们 不 考虑 为 了 安全 而 使 用 PIE 技 术 ) 。 如 果 编 译 时 没有 传 给 
编译 如 参数 "-fPIC"， 那 么 对 于 引用 的 外 部 的 全 局 变量 ， 可 执行 程序 不 使 用 
GOT 表 的 方式 寻 址 。 换 句 话 说 ， 可 执行 程序 引用 的 变量 ， 在 编译 链接 时 整 
需要 在 编译 链接 时 确定 好 地 址 ， 不 能 在 加 载 时 再 进行 重 定位 。 


但 是 ， 编 译 时 动态 库 都 不 能 确定 自己 的 变量 的 最 终 加 载 地 址 ， 更 别提 
可 执行 程序 了 。 那 怎么 办 呢 ? 于 是 ELF 标 准 定义 了 一 种 新 的 重 定位 类 型 一 
R_386_COPY。 对 于 这 种 重 定位 类 型 ， 编 译 器 、 链 接 器 和 动态 链接 大 是 这 样 
协作 的 : 编译 时 ， 编 译 妖 将 偷偷 地 在 可 执行 程序 的 BSS 段 创建 了 一 个 变量 ， 
这 样 就 解决 了 编译 时 ， 变 量 地 址 不 确定 的 问题 。 在 程序 加 载 时 ， 动 态 链接 
器 将 动态 库 中 的 变量 的 初 值 复制 到 可 执行 程序 的 BSS 段 中 来 。 然 后 ， 动 态 库 
(包括 其 他 动态 库 ) 在 引用 这 个 变量 时 ， 因 为 可 执行 程序 在 link_map 的 最 前 
面 ， 所 以 解析 符号 都 将 使 用 可 执行 程序 中 的 这 个 偷偷 创建 的 变量 。 


下 面 我 们 结合 hello 引 用 动态 库 libf1 中 的 变量 foo1 来 具体 的 讨论 一 下 。 移 
来 看 一 下 hello 的 动态 符号 表 : 


root@baisheng:~/demo# readelf -s hello 


Symbol table '.dynsym' contains 17 entries: 
Num: Value Size Type Bind Vis Ndx Name 


12: 0804a040 4 OBJECT GLOBAL DEFAULT 25 EOGL 


虽然 我 们 没有 在 可 执行 程序 中 定义 变量 foo1， 但 是 根据 动态 符号 表 可 
见 ， 可 执行 程序 hello 中 却 定义 了 变量 foo1， 其 所 在 地 址 是 0x0804a028， 而 且 
在 第 25 个 段 中 。 我 们 来 看 看 第 25 个 段 是 什么 : 


root@baisheng:~/demo# readelf -S hello 


Section Headers: 
[Nr] Name Type Addr QFEE Size 


[25] .bss NOBITS 0804a040 00102c 002020 


可 见 ， 第 25 个 段 是 .bss。 也 就 是 说 ， 编 译 时 ， 链 接 器 为 可 执行 程序 hello 
定义 了 一 个 未 初始 化 的 全 局 变量 foo1。 而 hello 中 ， 使 用 的 恰恰 是 hello 目 己 的 
foo1， 而 不 是 库 libf1 中 的 foo1。 观 察 下 面 中 引用 的 符号 foo1 的 地 址 ， 正 是 
hello 中 定义 的 符号 foo1 的 地 址 : 


root@baisheng:~/demo# objdump -d hello 
080485cc <main>: 


80485e5 : c7 05 40 a0 04 08 05 movl $0Ox5, 0x804a040 


链接 器 将 hello 的 重 定位 表 中 foo1l 的 重 定位 类 型 设置 为 R_386_COPY， 当 
处 理 这 个 类 型 的 重 定位 时 ， 动 态 链接 器 将 在 加 载 时 ， 将 库 libf1 中 变量 foo1 的 
值 复制 到 hello 中 的 fool: 


root@baisheng:~/demo# readelf -r hello 


Relocation section '.rel.dyn' at offset 0x420 contains 2 entries: 
Offset Info Type Sym.Value Sym. Name 
08049ffc 00000406 R 386 GLOB DAT 00000000  _ gmon start _ 


0804a040 00000c05 R 386 COPY 0804a040 fool1 


下 面 我 们 将 程序 运行 起 来 ， 动 态 观察 一 下 R_386_COPY 类 型 的 重 定 位 过 
程 。 
root@baisheng:~/demo# gdb ./hello 
(gdb) b main 
Breakpoint 1 at 0x80485cf 


(Gai) 至 
Starting program: /root/demo/hello 


Breakpoint 1, 0x080485cf in main () 


理论 上 ， 动 态 链 接 器 应 该 将 库 libf1 中 的 foo1 的 初 值 10 复 制 到 hello 中 定义 
的 foo1 处 。 我 们 将 hello 中 定义 变量 foo1 所 在 地 址 实际 的 值 打印 出 来 : 


(gdb) x 0x0804a040 
0x804a040 <fool>: 0x0000000a 


可 见 ，hello 中 的 fool 已 经 被 赋值 为 库 libf1 中 的 foo1 的 初 值 10 了 。 


另外 ， 库 libf1 中 GOT 表 中 保存 的 foo1 的 地 址 ， 也 应 该 指向 hello 中 定义 的 
fool 的 地 址 ， 而 不 是 库 libf1 中 的 变量 foo1 的 地 址 。 原 因 是 链接 时 ， 可 执行 程 
序 排 在 链表 link_map 的 表 头 ， 所 以 hello 中 的 符号 foo1 当 然 要 优先 于 库 libf1 中 
的 foo1。 我 们 来 实际 验证 一 下 这 一 点 ， 首 先 找 到 库 libf1 中 变量 foo1 所 在 位 
置 : 


root@baisheng:~/demo# readelf -r libfl.so 


Relocation section '.rel.dyn' at offset 0x38c contains 11 entries: 
Offset Into Type Sym.Value Sym. Name 


00001ff8 00000c06 R 386 GLOB DAT 0000201c fool 


在 另外 一 个 终端 中 查看 库 libf1 在 进程 hello 的 地 址 至 间 中 映射 的 基 址 : 


root@baisheng:~/demo# ps -C hello -o pid= 
3346 
root@baisheng:~/demo# cat /proc/3346/maps 
08048000-08049000 r-xp 00000000 08:01 1054223 /root/demo/hello 


b7fd8000-b7fd9000 r-xp 00000000 08:01 1047105 /root/demo/libfl1.so 


库 libf1 的 GOT 表 中 记录 符号 foo1 的 地 址 是 : 
Oxb7fd8000 + Oxlff8 = Oxb7fd9ff8 
我 们 打印 一 下 GOT 表 中 的 值 : 


(gdb) x 0xb7fd9ff8 
Oxb7fd9ff8: 0x0804a040 


根据 输出 可 见 ， 地 址 0x0804a040 正 是 hello 中 定义 的 符号 fool 的 地 址 。 可 
， 动 态 库 libf1 中 使 用 的 foo1 变 量 是 可 执行 程序 中 创建 的 这 个 副本 。 显 然 ， 


虽然 这 个 副本 仅仅 是 编译 右 为 其 偷偷 分 配 的 ， 但 是 实际 已 经 取代 了 库 ]ibf1 
中 的 foo1， 已 经 转正 了 。 


当然 ， 在 编译 可 执行 程序 时 也 可 以 给 其 传递 参数 "-fPIC"， 如 此 ， 可 执 
行程 序 中 对 外 部 变量 的 应 用 也 将 采用 GOT 表 的 方式 ， 但 是 这 对 可 执行 程序 
没有 任何 意义 。 


5.4.8 重 定 位 动态 链接 器 


在 Linux 中 ， 动 仿 链 接 融 被 实现 为 一 个 动态 库 的 形式 ， 而 且 这 个 动态 库 
是 自 包 含 的 (self-contained) ， 没 有 引用 其 他 库 的 符号 ， 但 是 与 普通 动态 库 
一 样 的 道理 ， 它 在 编译 时 也 不 知道 目 己 的 确切 位 置 ， 所 以 它 也 难 逃 重 定位 
的 命运 。 事 实 上 ， 当 C 库 加 载 后 ， 动 态 链 接 使 用 了 C 库 中 的 内 存 管理 相关 画 
数 蔡 换 了 目 身 的 实现 。 


查看 一 下 动态 链接 器 的 重 定位 表 就 可 见 其 需要 重 定位 的 符号 : 


root@baisheng:/vita/sysroot/lib# readelf -r ld-2.15.so 


Relocation section '.rel.dyn' at offset 0x6d0 contains 13 entries: 
Offset Info Type Sym.Value Sym. Name 
00020e48 00000008 R 386 RELATIVE 


00020ffc 00000606 R 386 GLOB DAT 00015780 free 


Relocation section '.rel.plt' at offset 0x738 contains 6 entries: 
Offset Info Type Sym.Value Sym. Name 
0002100c 00000b07 R 386 JUMP SLOT 000155e0 __libc memalign 
00021010 00001607 R 386 _ JUMP SLOT 000156f0 malloc 

00021014 00000d07 R 386 JUMP SLOT 00015720 calloc 

00021018 00000707 R 386 JUMP SLOT 00015860 realloc 

0002101cC 00001207 R 386 JUMP SLOT 00011f50 __tls get addr 
00021020 00000607 R 386_ JUMP SLOT 00015780 free 


但 是 ， 与 动态 库 和 可 执行 程序 不 同 ， 它 们 有 动态 链接 器 负责 为 它们 重 
定位 ， 而 动态 链接 右 则 没有 这 么 好 的 命 。 在 内 核 跳 转 到 动态 链接 器 时 ， 它 
古 非 第 残 酶 的 ， 并 没有 给 动态 链接 右 如 link_map 人 信息。 好 在 动态 链接 如 不 依 
赖 其 他 的 动态 库 ， 只 需要 确定 自己 被 加 载 的 基地 址 ， 然 后 找到 动态 链接 需 


要 的 段 .dynamic 束 可 以 解决 问题 ， 后 续 的 重 定位 过 程 与 动态 库 的 过 程 基 本 完 
全 相同 。 因 此 ， 动 态 链 接 器 重 定位 目 己 的 关键 是 : 


令 确定 目 己 被 加 载 的 基地 址 ; 
令 找到 段 .dynamic 。 


动态 链接 器 被 加 载 的 地 址 就 相当 于 link_map 中 的 1]_addr 了 。 运 行 后 ， 动 
态 链接 器 可 以 获取 到 某 个 符号 的 地 址 ， 但 是 这 并 不 足以 计算 出 动态 链接 器 
在 进程 地 址 空间 中 映射 的 基 址 ， 只 有 对 比 ， 才 能 求 出 基 址 。 因 此 ， 动 态 链 
接 器 还 是 需要 编译 时 的 链接 器 作 一 点 小 小 的 配合 。 在 编译 时 ， 链 接 器 定义 


了 


个 符号 "_DYNAMIC": 


root@baisheng:/vita/sysroot/lib# readelf -s ld-2.15.so 
Symbol table '.symtab' contains 584 entries: 
Num: Value Size Type Bind Vis Ndx Name 
353;5 00020£3¢ 0 OBJECT LOCAL DEFAULT 15 DYNAMIC 


511: 00021000 0 OBJECT LOCAL DEFAULT 17 GLOBAL OFFSET TABLE 


定义 这 个 符号 的 目的 吏 是 为 了 标识 段 .dynamic 所 在 的 地 址 ， 看 下 面 动态 


链接 器 的 Section Header Table: 


root@baisheng:/vita/sysroot/lib# readelf -3S ld-2.15.so 


Section Headers: 
[Nr] Name Type Addr Off Size 


[15] .dynamic DYNAMIC 00020f3c 01ff3c 0000b8 


由 上 可 见 ， 符 号 _DYNAMIC 的 地 址 正 是 段 .dynamic 的 地 址 。 在 运行 
上 时， 动态 链 接 器 使 用 如 x86 指 令 lea 读 取 符 号 _DYNAMIC 的 运行 时 地 址 ， 实 
际 惑 是 读 取 运 行 时 段 .dynamic 的 地 址 。 


除了 定义 了 这 个 从 号 外 ， 在 编译 时 ， 上 段 .dynamic 的 地 址 也 被 流 载 到 了 
GOT 表 中 的 第 1 项 。 读 者 回忆 一 下 在 5.4.6 节 讨论 GOT 表 时 的 内 容 。 其 中 ， 第 
2 项 的 link_map 和 第 3 项 的 解析 函数 我 们 都 已 经 看 到 其 作用 了 ， 但 是 尚未 看 到 
第 1 项 的 意义 。 在 重 定位 动态 链接 器 时 ， 这 一 项 发 挥 了 关键 作用 。 前 面 我 们 
就 已 经 看 到 过 ， 编 译 时 定义 了 另外 一 个 符号 _GLOBAL_OFFSET_TABLE_， 
目的 与 _DYNAMIC 相 似 ， 是 为 了 标识 GOT 表 的 地 址 。 因 此 ， 动 态 链 接 器 就 
可 以 使 用 符号 _GLOBAL_OFFSET_TABLE 找到 GOT 表 ， 从 而 取出 GOT 表 
中 第 1 项 的 值 。 


然后 ， 使 用 取得 的 符号 _DYNAMIC， 也 就 是 段 .dynamic 的 运行 时 地 
址 ， 与 GOT 表 第 一 项 在 编译 时 保存 的 段 .dynamic 的 地 址 (其 是 相对 于 0 的 ) 
做 差 ， 得 出 的 就 是 动态 链接 右 在 进程 地 址 空间 映射 的 基 址 了 。 相 关 代 码 如 
平 : 


glibc-2.15/elf/rtld.c: 


static ElfW(Addr) attribute used internal function 
_Gl1 start (void *arg) 


{ 
bootstrap map.l1 addr = elf machine load address (); 


/* Read our own dynamic section and fill in the info array. */ 
bootstrap map.l1 ld = (void *) bootstrap map.]1] addr + 

elf machine dynamic (); 
elf get dynamic info (&bootstrap map, NULL); 


注意 变量 bootstrap_map， 相 信 从 名 字 读 者 已 经 猜 出 来 了 ， 相 当 于 代表 
普通 动态 库 和 执行 程序 的 link_map。 而 且 根据 这 个 变量 的 名 字 ， 我 们 也 可 以 
揣摩 到 开发 者 的 用 意 是 在 表达 这 是 动态 链接 器 的 自 举 过 程 。 变 量 
bootstrap_map 中 的 关键 两 项 读者 应 该 非常 熟悉 了 ，1_addr 是 代表 动态 链接 器 
目 己 被 映射 的 地 址 ，]L_1d 代 表 动 态 链 接 硕 的 段 .dynamic 所 在 的 地 址 。 找 到 


段 .dynamic 后 ， 动 态 链 接 絮 调用 elf_get_dynamic_info 读 取 了 这 个 段 的 信息 。 


我 们 来 看 看 获取 1]_addr 和 1]_1d 这 两 个 地 址 的 函数 : 


glibc-2.15/sysdeps/i386/dl-machine.h: 


static inline Elf32 Addr attribute _ ((unused, const)) 
elf machine dynamic (void) 
extern const Elf32 Addr GLOBAL OFFSET TABLE [] 
attribute hidden; 
return GLOBAL OFFSET TABLE [0]; 


} 


static inline Elf32 Addr attribute _ ((unused)) 
elf machine load address (void) 


{ 


extern Elf32 Dyn bygotoff[] asm (" DYNAMIC") attribute hidden; 
return (Elf32 Addr) &bygotoff - elf machine dynamic (); 


} 


函数 elf_machine_dynamic 利 用 在 编译 时 定义 的 符号 
_GLOBAL_ OFFSET_TABLE 读 取 GOT 表 中 第 0 项 的 值 。 


函数 elf_machine load_address 计 算 动 态 链 接 器 加 载 的 地 址 。 其 首先 取得 


一 /一 


符号 _ DYNAMIC 的 运行 时 地 址 ， 对 于 x86 来 说 ， 可 以 使 用 指令 lea， 然 后 与 


GOT 表 中 保存 的 编译 时 的 地 址 做 老 ， 从 而 得 出 动态 库 在 进程 地 址 至 间 中 有 映 
味 的 基 址 。 


事实 上 ， 动 态 连接 器 重 定位 表 中 的 那些 动态 内 存 管理 的 函数 ， 如 
malloc、free 等 ， 最 初 动 态 链 接 絮 使 用 的 是 自己 内 部 的 实现 : 


glibc-2.15/elf/dl-minimal.c: 

Void * weak function malloc (size 七 n) 
{ 

} 


VolQ weak function free (void *ptr) 


{ 


但 是 一 旦 C 库 加 载 后 ， 动 态 链接 万 将 再 次 重 定位 这 几 个 函数 ， 使 用 C 库 
中 的 相应 实现 。 


5.4.9 段 RELRO 


最 初 ， 编 译 时 链接 船 并 没有 过 多 考虑 ELF 文 件 中 各 个 段 的 布局 ， 一 个 
ELF 文 件 各 个 段 的 大 致 布局 如 图 5-38 所 示 。 


Code Segment Data Segment 
(ro & exec) (rw) 


| .bss overflow 


.data overflow 


.text section, ... .data section .got section, .., .bss section 


图 5-38 早期 ELF 文 件 段 的 布局 


可 见 ， 动 态 链接 器 重 定位 涉及 的 GOT 表 、 段 .dynamic 都 位 于 数据 段 的 后 
面 ， 一 旦 数据 段 发 生 湾 出 ， 动 态 链接 硕 使 用 的 GOT 表 、 段 .dynamic 都 可 能 受 
到 破坏 ， 尤 其 是 作为 函数 跳 转 表 的 GOT 表 ， 更 容易 被 攻击 者 利用 。 而 事实 
上 ， 除 了 画 数 被 延迟 到 运行 时 重 定位 外 ， 变 量 等 的 重 定位 在 加 载 时 就 已 经 
完成 了 ， 后 续 动 态 链接 器 不 再 会 对 这 些 段 进 行 写 操作 ， 也 了 束 是 说 完全 可 以 
在 完成 加 载 时 重 定位 后 ， 把 这 部 分 数据 修改 为 只 读 。 


因此 ， 如 今 的 链接 郁 重 狐 安 排 了 各 个 段 的 布局 ， 将 动态 链接 融 涉 及 到 
的 段 所 到 了 数据 段 的 前 面 ， 并 将 GOT 拆 分 为 两 个 部 分 : .got 和 .got.plt。.got 
部 分 用 于 记录 需要 重 定位 的 变量 ，.got.plt 部 分 用 于 记录 需要 重 定位 的 函数 。 
在 加 载 时 完成 重 定位 后 ， 除 了 .got.plt 仍 然 保 留 可 写 属性 ， 人 允许 在 运行 时 进行 
重 定位 外 ， 包 括 .got 在 内 的 其 余部 分 全 部 更 改 为 只 读 ， 减 少 被 攻击 的 可 能 。 


这 些 在 重 定 位 后 更 改 为 只 读 的 段 被 称 为 RELRO 段 。 从 Program Header 
Table 的 角度 看 ， 段 RELRO 仍 然 包含 于 数据 段 中 ， 只 不 过 是 数据 段 开 头 部 分 
一 块 只 读 的 数据 而 已 。 经 过 上 述 调 整 后 ， 一 个 ELF 文 件 的 大 致 布局 演化 为 如 
图 5-39 所 示 的 形式 。 


Code Segment Data Segment 


(ro & exec) pe 


.data section = .bss overflow 


.data overflow 


.bss section 


.got section, 


.text Section，,.， 
RELRO 
Segment 
(ro) 


图 5-39 ”使 用 RELRO 后 ELF 文 件 的 布局 


.got.plt section 


在 加 载 时 完成 重 定位 后 ， 动 态 链 接 器 将 检查 ELF 文 件 的 Program Header 
Table 中 是 否 存 在 段 RELRO。 如 果 这 个 段 存在 ， 则 将 这 个 段 更 改 为 只 读 ， 从 
而 达到 保护 更 多 数据 的 目的 。 相 关 代 码 如 下 : 


glibc-2.15/elf/dl-reloc.c: 


void dl relocate object (struct link map *1, ...) 


{ 


if {l=31 relro size 4= 0) 
_d1 protect relro (1); 


} 


void internal function dl protect relro (struct link map *]1) 


{ 


if (start != end 
&& _ mprotect ((void *) start, end - start, PROT READ) < 0) 


其 中 _d]_relocate_object 就 是 动态 链接 中 负责 加 载 时 重 定位 的 函数 。 在 这 
个 函数 的 最 后 ， 也 就 是 加 载 时 重 定位 完成 后 ， 这 个 函数 调用 
_d]_protect_relro 修 改 段 RELRO 的 权限 为 只 读 。 函 数 _d]_protect_relro 远 辑 非 
党 简单 ， 就 是 通过 函数 _、mprotect 请 求 内 核 更 改 段 RELRO 的 属性 为 
PROT_READ 。 


编译 时 链接 器 并 没有 强制 使 用 RELRO 这 个 特性 ， 如 果 需 要 使 用 这 个 特 
性 ， 在 链接 时 需要 向 链接 器 传递 参数 "-z relro"。 以 笔者 使 用 的 Ubuntu12.10 
为 例 ， 可 以 看 到 在 编译 时 编译 器 确实 给 链接 器 传递 了 这 个 参数 ， 注 意 下 面 
使 用 黑体 标识 的 部 分 : 


root@baisheng:~# gcc -dumpspecs 


*]ink command: 
S${!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) ...-z relro ... 


在 我 们 构建 的 工具 链 中 ， 为 简单 起 见 ， 并 没有 默认 司 用 RELRO 符 性 。 


理解 了 RELRO 的 设计 动机 以 及 理论 背景 后 ， 我 们 结合 一 个 实例 来 具体 
体验 一 下 这 个 特性 。 以 下 面 程序 为 例 : 


hello.c: 
#include <stdlib.h> 


VOLd, marrt) 


{ 
} 


while(1) sleep(1000),， 


我 们 使 用 如 下 命令 分 别 编译 不 支持 RELRO 特 性 和 支持 RELRO 特 性 的 两 
个 可 执行 程序 : 
vita@baisheng:~$ i686-none-linux-gnu-gcc -o hello hello.c 


vita@baisheng:~$ i686-none-linux-gnu-gcc -Wl,-z,relro \ 
-DO hello relro hello.c 


其 中 ，haello 是 不 支持 RELRO 特 性 的 ，hello_relro 是 支持 RELRO 特 性 
的 。 我 们 首先 对 比 一 下 这 两 个 程序 的 Program Header Table，hello 的 Program 
Header Table 如 下 : 


vita@baisheng:~$ readelf -1 hello 


Program Headers: 


Type Offset VirtAddr PhysAddr FileSiz MemSiz 
PHDR Ox000034 0x08048034 0x08048034 0x00100 0x00100 
GNU_ STACK Ox000000 0x00000000 0x00000000 0x00000 0x00000 


hello_relro 的 Program Header Table 如 下 : 


vita@baisheng:~$ readelf -1 hello relro 


Program Headers: 


Type Offset VirtAddr PhysAddr FileSiz MemSiz 
LOAD Ox000000 0x08048000 0x08048000 0x00608 0x00608 
LOAD 0x000f20 0x08049f20 0x08049f20 0x00100 0x00108 
GNU_STRACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 
GNU RELRO 0x000f20 0x08049f20 0x08049f20 0x000e0 0x000e0 


Section to Segment mapping: 
Segment Sections . . . 


08 “CtOrs .dtors .jer .dynamde .got 


留意 hello_relro 的 Program Header Table 中 使 用 黑体 标识 的 部 分 。 显然， 
相 比 于 程序 hello，hello_relro 中 多 了 段 "GNU_RELRO" 。 


读者 可 能 会 有 个 疑问 ， 前 面 不 是 提 到 内 核 只 加 载 ELEF 文 件 中 类 型 为 
LOAD 的 段 吗 ， 那 么 这 个 类 型 为 GNU_RELRO 的 段 会 被 加 载 吗 ? 请 仔细 观察 
段 RELRO 与 第 2 个 类 型 为 LOAD 的 段 〈 即 数据 段 ) 的 Offset 一 列 ， 可 见 
RELRO 段 在 hello_relro 中 俩 移 与 数据 段 在 hello_relro 文 件 中 的 侦 移 相同 。 换 
句 话说 ，RELRO 段 正 是 数据 段 的 开头 部 分 ， 所 以 在 加 载 数据 段 时 ， 已 经 隐 
含 着 将 段 RELRO 加 载 了 。 


接 下 来 ， 我 们 再 来 动态 的 观察 一 下 特性 RELRO“。 这 里 偷 个 懒 ， 因 为 目 
标 系统 也 是 x86 的 ， 所 以 笔者 直接 在 宿主 系统 上 运行 了 ， 读 者 当然 可 以 将 
hello_relro 复 制 到 目标 系统 做 这 个 试验 。hello 的 进程 地 址 空间 的 映射 情况 如 
平 。 


vita@baisheng:~$ ./hello & 


[1] 4320 

vita@baisheng:~$ cat /proc/4320/maps 

08048000-08049000 r-xp 00000000 08:03 9447286 /home/vita/hello 
08049000-0804a000 rw-p 00000000 08:03 9447286 /home/vita/hello 


b753e000-b753f000 rw-p 00000000 00:00 0 


hello_relro 的 进程 地 址 空间 的 映射 情况 如 下 : 


vita@baisheng:~$ ./ hello relro & 

[2] 4328 

vita@baisheng:~$ cat /proc/4328/maps 
08048000-08049000 r-xp 00000000 08:03 9447303 


/home/vita/hello relro 
08049000-0804a000 r--p 00000000 08:03 9447303 

/home/vita/hello relro 
0804a000-0804b000 rw-p 00001000 08:03 9447303 

/home/vita/hello relro 
b7559000-b755a000 rw-p 00000000 00:00 0 


对 比 hello 和 hello_relro 的 进程 空间 的 映射 情况 ， 注 意 hello_relro 映 射 中 使 
用 黑体 标识 的 部 分 ， 可 见 ，hello_relro 在 0x08049000~0x0804a000 多 映射 了 一 
个 只 读 的 段 ， 没 错 ， 这 个 段 就 是 段 RELRO。 显 然 ， 因 为 其 与 后 面 的 数据 段 
权限 不 同 ， 所 以 内 核 为 这 个 段 单独 分 配 了 一 个 vm_struct_area 对 象 。 


事实 上 ， 不 仅 是 可 执行 程序 ， 动 态 库 也 是 如 此 。 读 者 可 以 自己 做 些 对 
比试 验 ， 这 里 不 再 区 述 。 


第 6 章 ” 构 建 根 文件 系统 


在 第 3 章 中 ， 我 们 通过 手工 的 方式 展示 了 从 零 构 建 根 文件 系统 的 过 程 。 
在 本 章 中 ， 我 们 将 构建 一 个 相对 完善 的 根 文件 系统 ， 但 是 我 们 不 再 从 零 开 
始 ， 和 毕竟 一 旦 熟悉 了 原理 后 ， 余 下 的 就 是 简单 的 重复 了 。 第 2 章 编 译 工具 链 
时 曾 通 过 参数 "--with-sysroot" 指 是 了 目标 系统 的 文件 安 狠 的 目录 ， 后 续 所 有 
的 为 目标 系统 编译 的 文件 全 部 安装 到 了 这 个 目录 下 。 因 此 ， 在 本 章 中 ， 我 
们 束 基 于 这 个 目录 下 的 文件 构建 运行 在 真实 系统 上 的 根 文件 系 统 。 


为 了 更 高 效 地 开发 调试 ， 我 们 首 允 打通 了 目标 系统 的 网 络 ， 建 立 了 将 
主 系统 与 目标 系统 的 桥架 ， 包 括 配置 内 核 文 持 网 络 协议 以 及 网 卡 驱 动 ， 并 
安装 了 用 户 空间 的 网 络 配置 工具 。 如 此 ， 我 们 就 可 以 远程 登录 到 目标 系统 
上 进行 调试 ， 并 且 可 以 动态 更 新 文件 ( 除 内 核 和 initramfs 外 ) 而 不 必 再 每 次 
都 重 局 系统 。 


几乎 所 有 的 现代 操作 系统 都 提供 图 形 用 户 界面 ，Linux 也 不 例外 。 硫 省 
理工 的 开发 者 们 为 UNIX 系 统 开发 了 X 窗 口 系统 (X Window System， 简 称 X 
或 者 X11) 作为 图 形 环境 。 除 了 X 外 ， 另 外 一 个 需要 关注 的 图 形 环 境 是 
Wayland。 虽 然 wayland 的 目标 是 奉 代 X， 并 且 开 源 社区 也 支持 Wayland 向 着 
这 个 方向 发 展 ， 但 是 wayland 距 广泛 使 用 还 有 一 段 路 要 走 。 因 此 ， 在 本 章 
中 ， 我 们 依然 以 目前 广泛 使 用 的 X 构 建 基础 的 图 形 环境 ， 并 安装 了 GTK 作 为 
更 上 层 的 图 形 库 。 事 实 上 ，Wayland 更 像 是 X 的 一 次 整合 或 者 重 构 ， 在 第 8 章 


探讨 Linux 的 图 形 原理 时 ， 我 们 会 拿 出 一 点 篇 幅 讨 论 Wayland， 在 那里 我 们 
会 看 到 ，Wayland 和 X 之 间 并 无 本 质 区 别 。 


6.1 初始 根 文件 系统 


因为 我 们 使 用 的 是 vita 用 户 进行 编译 过 程 ， 所 以 $SYSROOT 目 了 永 下 的 所 
有 文件 的 属 主 和 属 组 都 是 vita， 如 有 果 对 安全 问题 有 有 顾虑， 在 最 终 将 其 作为 根 
文件 系统 时 ， 可 以 将 该 目录 下 的 所 有 文件 ， 包 括 目 录 的 属 主 和 属 组 ， 更 改 


为 root 。 


另外 ， 为 简单 起 见 ， 我 们 也 没有 考虑 文件 系统 的 大 小 。 如 果 是 为 一 个 
真实 的 系统 制作 根 文件 系统 ， 那 么 可 以 考虑 进行 一 些 优化 ， 比 如 对 二 进 制 
文件 和 动态 库 使 用 命令 strip 删 除 一 些 运行 时 不 需要 的 信息 和 符号 表 等 ， 删 除 
那些 只 是 在 编译 时 使 用 的 头 文件 和 静态 库 ; 等 等 。 


上 面 讨论 的 都 不 是 必须 的 ， 如 果 仅 作为 一 个 用 于 测试 的 系统 ， 完 全 可 
以 不 必 理 会 ， 下 面 是 必须 要 做 的 几 件 事 。 


(1) 安装 GCC 库 


在 前 面 编 译 GCC 时 ， 我 们 已 经 看 到 ，GCC 也 将 部 分 底层 函数 封 泌 到 库 
中 ， 很 多 程序 会 使 用 GCC 的 这 些 库 ， 因 此 ， 我 们 也 将 这 部 分 程序 安装 到 根 
文件 系统 中 。 我 们 只 安装 运行 时 使 用 的 动态 库 及 对 应 的 运行 时 符号 链接 ， 
当然 ， 系 统 中 并 不 一 定 会 用 到 全 部 这 些 库 ， 但 是 简单 起 见 ， 这 里 全 部 安装 
J 


vita@baisheng:/vitas$ cp -d \ 
cross-tool/i686-none-linux-gnu/lib/lib*.so.*[0-9] \ 
rootfs/lib/ 


(2) 建立 相关 目录 


在 前 面 讨论 从 initramfs 切 换 到 根 文件 系统 时 ， 我 们 看 到 ， 切 换 程序 将 最 
初 挂 载 到 文件 系统 rootfs 中 的 /dev、/run、/proc 和 /sys 目 录 移 动 到 真正 的 根 文 
件 系统 ， 因 此 ， 我 们 需要 在 根 文 件 系统 上 建立 这 几 个 目录 。 另 外 我 们 也 为 
root 用 户 建立 一 个 属 主 root 目 录 : 


vita@baisheng:/vita/sysroots$ mkdir sys proc dev run root 


(3) 构建 程序 /sbin/init 


在 内 核 初始 化 的 最 后 ， 启 动 的 第 一 个 进程 要 装载 用 户 空 间 的 程序 从 而 
切入 用 户 空间 ， 通 常 这 个 程序 是 /sbin 目 录 下 的 init， 因 此 我 们 要 准备 这 个 程 
序 。 为 简单 起 见 ， 我 们 也 使 用 shell 脚 本 编写 : 


/vita/sysroot/sbin/init: 


#!/bin/bash 
export HOME=/root 
exec /bin/bash -1 


init 局 动 了 一 个 交互 式 的 shell。 其 中 传递 的 参数 "-]" 是 告诉 bash 以 登录 方 
式 启动 ， 这 样 可 以 使 bash 读 取 在 /etc/profile、~/.profile 等 文件 中 定义 的 环境 
变量 。 同 时 要 确保 init 程 序 具有 可 执行 权限 : 


vita@baisheng:/vita/sysroot/sbins$s chmod a+x init 


为 了 让 shell 提 示 符 看 上 去 友好 一 些 ， 更 重要 的 是 为 了 后 面 当 从 和 窒 主 系 
统 远 程 登录 到 vita 系 统 时 ， 方 便 区 分 本 地 终端 和 登录 到 vita 的 终端 ， 我 们 在 
全 局 范围 的 profile 文 件 中 定义 了 环境 变量 PS1 来 控制 shell 提 示 符 的 显示 内 容 
和 风格 : 


/vita/sysroot/etc/profile: 


export PS1="\[\e[31;lm\] \u@vita:\[\e[35;1lm\] \w# \[\e[Om\]" 


其 中 ，"\u" 告 诉 shell 显 示 当 前 用 户 名 ; "\Ww" 告 诉 shell 显 示 完 整 的 工作 路 
径 ; 我 们 将 主机 名 直接 硬 编码 为 vita， 为 了 便于 区 分 是 本 地 的 终端 还 是 登入 
vita 的 终端 ， 接 下 来 我 们 给 提示 符 加 一 点 漂亮 的 颜色 ，"e[" 与 "m" 之 间 的 内 
容 表 示 颜 色 值 ， 在 它们 之 外 包围 的 [与 ”是 保证 其 内 的 非 打印 字符 ,不 
占用 任何 空间 。 颜 色 设置 的 格式 为 \[\e[F;B;CmN]"， 其 中 F 是 前 景色 ，B 是 背 
景色 ，C 是 一 些 表 示 特 殊 效 果 的 代码 ， 如 下 划 线 、 内 烁 等 。 


具体 到 我 们 这 个 例子 ， 其 中 31 表 示 红 色 ， 因 此 ,“ 用 户 名 @vita” 将 以 红 
色 显 示 ; 35 表 示 洋 红 ， 因 此 工作 路 径 将 以 详 红 色 显 示 。 最 后 ， 在 提示 符 结 
束 的 位 置 ， 我 们 通过 '"\e[0m" 将 颜色 值 设 定 为 零 ， 也 束 是 通知 终端 将 前 景 、 
育 景 重 置 为 它们 的 默认 值 ， 以 使 后 续 的 文字 以 非 彩色 显示 。 


接 下 来 将 $SYSROOT 目 孙 整 个 复制 到 虚拟 机 ， 因 为 命令 scp 会 跟随 符号 
链接 ， 所 以 我 们 采用 先 压 缩 、 再 复制 的 办 法 ， 相 关 命令 如 下 : 


vita@baisheng:/vita/sysroots$ tar ZCVE ../sysroot.tgz * 
vita@baisheng:/vita/sysroots$ scp ../sysroot.tgz \ 
root@192.168.56.101:/root/ 


在 虚拟 机 上 执行 如 下 命令 解压 根 文 件 系 统 : 


root@baisheng-vb:/vita# tar xvf /root/sysroot.tgz 


6.2 ”以 读 写 模式 重 狐 挂 载 文 件 系统 


一 般 在 挂 载 文件 系统 之 前 ， 将 使 用 工具 fsck 检 查 文 件 系统 的 一 致 性 。 如 
果 文 件 系 统 中 存在 错误 ， 则 fsck 会 试图 修复 它们 ， 但 是 这 个 过 程 要 求 文件 系 
统 没 有 挂 载 或 以 只 读 方 式 挂 载 。 因 此 我 们 在 GRUB 的 配置 文件 grub.cfg 中 经 
党 看 到 内 核 的 命令 行 参数 中 有 这 人 么 一 个 字 串 "ro"， 其 是 "read only" 的 简写 ， 
目的 是 告诉 内 核 或 initramfs 最 初 以 只 读 方 式 挂 载 根 文件 系统 。 在 Linux 系 统 
进入 用 户 空间 、 使 用 工具 fsck 检 查 文件 系统 后 ， 然 后 再 以 读 写 方式 重新 挂 载 
根 文件 系统 。 这 里 我 们 忽略 文件 系统 检查 这 一 过 程 ， 直 接 以 读 写 模式 重新 
挂 载 根 文件 系统 。 


/vita/sysroot/sbin/init: 


#!/bin/bash 
mount -o remount,rw /dev/sda2 / 


export HOME=/root 
exec /bin/bash -1 


如 果 读 者 没有 更 改 根 文件 系统 中 文件 的 属 主 和 属 组 为 root， 那 么 更 新 
vita 系 统 的 /sbin/init 程 序 后 ， 重 启 系统 ， 我 们 来 检查 一 下 根 文件 系统 是 否 以 
读 写 方式 成 功 挂 载 『。 以 笔者 的 vita 系 统 为 例 ， 如 图 6-1 所 示 。 


11.10 [正在 运行 ] - Oracle VM VirtualBox 


ExT4-fs (sda2)}): recovery complete 

ExT4-fs (sda2}): mounted filesystem with ordered data mode. Opts: (null) 

tsc: Refined TSC clocksource calibration: 2386.298 MHz 

Switching to clocksource tsc 

mount: only root can use "--options" option (effective UID is 1001) 
: cannot set terminal process group (-1): Inappropriate ioctl for device 
: no job control in this shell 

lA 

root@vita:/A# cat /proc/mounts 

rootfs /2 rootfs rw Oo 

udev /dev devtmpfs rw,relatime,mode=0755 0 0 

proc “proc proc rw,relatime OO 


sUsfs /SUS SUsSfS rw,relatime 0 @ 

ramfs /run ramfs rw relatime © 0 

xdeuxsdaz ~ ext4 ro,relatime,data=ordered ©@ 0 
root@vuita:,/# 


rootBvita:/# touch x 
: Cannot touch ’x’: Read-only file system 


lACL De A ru “evwsda2 

mount: only root can use "~--options” option (effective UID is 1001) 
root@vuita:,/# 

rootBvita:/# ls -1 /bin/mount 

-rwsr-xr-x 1 1001 1001 103045 Jan 29 Q9:17?7 /bin/mount 


root@vita:/# _ 
习 悄 男 国 加 | 仿 回 右 ctrl 


图 6-1 重新 挂 载 文件 系统 失败 


使 用 cat 命 令 查看 "proc/mounts"， 发 现 根 文件 系统 依然 是 以 只 读 方 式 挂 
载 的 。 使 用 命令 touch 试 图 尝试 创建 一 个 文件 ， 创 建 也 以 失败 告终 ， 再 次 证 
明 根 文件 系统 确实 是 以 只 读 方 式 挂 载 的 。 我 们 手动 再 次 尝试 以 读 写 方式 重 
新 挂 载 根 文件 系统 ， 还 是 失败 了 ， 但 是 我 们 看 到 mount 命 令 提示 了 一 个 非常 
有 用 的 信息 : effective UID is 1001。 看 上 去 似乎 是 权限 出 了 问题 。mount 命 
令 只 允许 以 root 的 号 份 进行 挂 载 操 作 ， 所 以 EUID 应 该 是 0 才 对 ， 但 是 这 里 的 
EUID 却 是 1001， 这 个 1001 是 哪 来 的 呢 ? 


在 安装 时 ， 安 装 脚 本 设置 了 工具 mount 和 umount 的 SUID ， 相 关 脚 本 如 
下 : 


util-linux-2.22/Makefile 


install-exec-hook-mount: 
chmod 4755 S$ (DESTDIR) S$ (bindir) /mount 
chmod 4755 $ (DESTDIR) S$ (bindir) /umount 


使 用 ls 命令 查看 这 两 个 文件 的 信息 可 见 ，SUID 确 实 被 设置 了 : 


vita@baisheng:/vita/sysroot/bins$ 1s -1 *mount 
-rwsr-xr-x 1 vita vita 103045 Jan 29 17:17 mount 
-rwsr-xr-x 1 vita vita 40612 Jan 29 17:17 umount 


因此 ， 虽 然 进程 1 的 EUID 是 超级 用 户 root， 但 是 一 旦 执行 mount 命 令 
时 ， 其 EUID 将 降 为 vita 用 户 的 UID， 而 在 笔者 的 宿主 系统 上 ，vita 的 UID 正 
是 1001， 这 就 是 上 面 "effective UID is 1001" 的 来 源 。 而 mount 命 令 是 要 求 以 
超级 用 户 root 运 行 的 ， 但 是 此 时 进程 1 被 降级 为 1001，mount 命 令 自 然 拒 绝 执 
行 挂 载 任务 。 


因此 ， 我 们 需要 修改 mount 和 和 umount 的 属 主 和 属 组 为 root， 命 令 如 下 : 


root@baisheng:/vita/sysroot/bin# chown root.root mount umount 


更 改 属 主 和 属 组 会 导致 这 两 个 程序 的 SUID 也 会 被 丢弃 ， 但 是 对 我 们 来 
说 ， 这 没有 什么 问题 。 如 果 很 介意 mount 和 umount 的 SUID， 执 行 下 面 的 命 
令 重 新 设置 即 可 : 


root@baisheng:/vita/sysroot/bin# chmod 4755 mount umount 


读者 可 能 会 问 ， 第 4 章 在 讨论 initramfs 时 ， 也 使 用 了 mount， 那 时 为 什么 
没有 这 个 权限 问题 ? 原因 是 我 们 在 从 $SYSROOT 复 制 到 那个 手工 搭建 的 基 
本 的 根 文件 系统 时 ，SUID 被 丢弃 了 。 很 多 有 安全 要 求 的 领域 经 常 使 用 SUID 
这 个 技巧 ， 比 如 管理 员 通 常会 设置 一 些 网 络 服务 器 程序 的 SUID， 这 样 一 旦 
被 人 攻破 ， 也 不 能 获得 超级 用 户 root 的 权限 。SUID 是 个 比较 抽象 的 概念 ， 
通过 这 个 例子 ， 我 们 切实 体验 了 一 次 SUID。 


6.3 配置 内 核 文 择 网 络 


为 了 方便 牡 主 系统 与 目标 系统 传输 文件 ， 并 且 可 以 从 宿主 系统 登 
孙 到 目标 系统 ， 目 标 系统 需要 文 持 网 络 。 为 此 ， 需 要 配置 目标 系统 的 
内 核 支 持 TCP/IP 协 议和 网 卡 驱 动 。 


6.3.1 配置 内 核 文 持 TCP/IP 协 议 
我 们 首先 配置 内 核 使 其 文 持 TCP/IP 协 议 ， 步 又 如 下 : 
1) 执行 make menuconfig， 出 现 如 图 6-2 所 示 的 界面 。 


BUS Options (PCI etc.) ---> 
i formats / Emulations ---> 


6-2 配置 内 核 支持 TCP/IP (1) 


2) 在 图 6-2 中 ， 选 择 菜单 项 "Networking support"， 出 现 如 图 6-3 所 
示 的 界面 。 


| 目 Networktng opttons --->| 


『 
四 


图 6-3 配置 内 核 支 持 TCP/IP (2) 


3) 在 图 6-3 中 ， 选 择 菜单 项 "Networking options"， 出 现 如 图 6-4 所 
示 的 界面 。 


[MW] TCP/IP networking| 


图 6-4 配置 内 核 支 持 TCP/IP (3) 


4) 在 图 6-4 中 ， 选 中 "TCP/IP networking"，TCP/IP 协 议 配置 完成 。 


6.3.2 ”配置 内 核 文 持 网 卡 


接 下 来 我 们 配置 内 核 中 的 网 卡 驱 动 。 既然 是 为 网 卡 配置 驱动 ， 首 先 当 
然 需要 知道 系统 使 用 的 是 什么 网 卡 。 那 么 我 们 如 何 查看 目标 系统 的 网 卡 型 
号 呢 ? 对 于 普通 的 PC 来 说 ， 网 卡 一 般 是 连接 在 PCI 总 线 上 的 PCTI 设 备 ， 

我 们 不 考虑 通过 其 他 接口 (如 USB) 转换 的 网 卡 。 既 然 是 连接 在 PCI 总 线 
上 ， 读 者 一 定 想到 了 前 面 使 用 的 查看 硬盘 控制 器 信息 的 工具 lspci 。 


在 目标 系统 上 运行 lspci， 查 看 与 以 太 网 相关 的 设备 。 确 定 设备 所 在 的 
PCI 总 线 上 的 位 置 后 ， 查 看 这 个 网 卡 的 环境 变量 MODALIAS， 如 图 6-5 所 
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bash;: no job control in this shell 
root@vuita: /# 
root@vita:/# lspci 
:QQ.0 Host bridge: Intel Corporation 440Fx - B2441FX% PMC [Natoma] (rew QZ2) 
:01.0 ISA bridge: Intel Corporation 82371SB PIIxX3 ISA [NatomaxTriton II] 
:OO1.1 IDE interface;: Intel Corporation 82371fAB/EB/MB PIIX4 IDE (rev 01) 
:02.0 UGA compatible controller: InnoTek Systemberatung GmbH UirtualBox Graphi 
Adapter 
:QQ3.0 Ethernet controller: Intel Corporation B2540EM Giygabit Ethernet Controll 
(rev 0Q2) 
:04.0 SUstem peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service 
:95.9 Multimedia audio controller: Intel Corporation 82801AA hC 37 fudio Contr 
(rev O01) 
-OO USH controller;， hpbple Inc. KeULargo“Intrepid USB 
-0 Bridge: Intel Corporation 8237?1AB/-EB/MB PIIX4 ACPI (rev 08) 
-© SATA controller: Intel Corporation 828Q1HMZHEM (ICH8M”ICH8M-E) SATA Cont 
poller [LIhHCI mode] (rev OZ2) 
root@uita: /# 
root@vuita:/# cat /sys/devices/pciQ000\:000000\ :00、:03.0/uevent 
PCI_CLASS=20000 
PCI_ID=8086 : 100E 
PCI_SUBSYS_ID=8086; QQ1E 
PCI_SLOT_NAME=0000:00:03.0 
0DALIAS=pci :vOO000808610000100Esv000080386sd10000001EbcQZscO0i00 


root@vita:/# _ 
鲜 昌 少 虽 国电 | 息 图 右 ctrl 


图 6-5 查看 网 卡 控 制 右 信息 


根据 命令 lspci 的 输出 可 见 ， 在 总 线 号 为 0x00 的 PCI 总 线 上 ， 设 备 号 为 
0x03 的 设备 束 是 Intel 的 型 号 为 82540EM 于 兆 以 太 网 卡 。 


根据 内 核 通 过 sys 文 件 系 统 报 告 的 uevent 事 件 ， 我 们 可 以 清楚 地 看 到 ， 
环境 变量 MODALIAS 的 值 为 : 


pci:v00008086d0000100Esv00008086sd0000001Ebc02sc00i00 


以 设备 ID"100E" 在 内 核 的 drivers/net 目 录 下 搜索 ， 结 果 如 下 : 


vita@baisheng:/vita/build/linux-3.7.4/drivers/nets grep "100E" \ 
-Ir * 


ethernet/chelsio/cxgb/elmer0.h: ELMERO XC2S100E 6TQ144 C 
ethernet/intel/e1000/e1000 main.c: 

INTEL E1000 ETHERNET DEVICE (0x100E) ， 
ethernet/intel/e1000/e1000 hw.h:#define E1000 DEV_ID 82540EM 


0x100E 
fddi/defxx.h:#define PI_ITEM K_SMT_HI_VERS_ID 0x100E 
fddi/skfp/pmf.c: { SMT P100E,AC 6G, 

MOFFSS (fddisMTHiVersionId), "Sn 于 

fddi/skfp/h/smt p.h:#define SMT P100E 0xl00e 
wireless/adm8211.c: ADM8211 CSR WRITE(MMIWA, 0x100EOCORA) ; 


根据 上 面 输出 结果 中 使 用 黑体 标识 的 部 分 可 见 ， 驱 动 e1000 声 明 对 设备 
ID 为 "100E" 的 设备 负责 。 也 束 是 说 ， 张 动 e1000 是 Intel 82540EM 于 兆 以 太 网 
卡 的 驱动 。 因 此 ， 我 们 需要 配置 内 核 支 持 e1000 驱 动 ， 配 置 步 骤 如 下 : 


1) 执行 make menuconfig， 出 现 如 图 6-6 所 示 的 界面 。 


etwor ; fr 
| 国 evice Drivers 
Firmwar Ei 


图 6-6 配置 内 核 支 持 网 卡 驱动 (1) 


2) 在 图 6-6 中 ， 选 择 荣 单项 "Device Drivers"， 出 现 如 图 6-7 所 示 的 界 
面 o 


1 - 
] Network device support --->| 
Tr l 对 记 UDr i ; 


图 6-7 配置 内 核 支 持 网 卡 驱动 (2) 


3) 在 图 6-7 中 ， 选 中 菜单 项 "Network device support"， 出 现 如 图 6-8 所 示 
的 界面 。 


图 6-8 配置 内 核 支持 网 卡 驱 动 (3) 


4) 在 图 6-8 中 ， 选 中 菜单 项 "Ethernet driver support"， 出 现 如 图 6-9 所 示 
的 界面 。 


"eT 
} FRU/IUU 


R) PRO/10600 Gigabit Ethernet support| 
R /1€ [- (Cr 由 3 l hi 十 访 6 一 


InteLf 
ntelt 
; 


Intel(R) Ff 
’ 和 Exp ul 


图 6-9 配置 内 核 支 持 网 卡 驱动 (4) 
5) 在 图 6-9 中 ， 将 "Intel(R)PRO/1000 Gigabit Ethernet support" 配 置 为 模 
块 ， 网 卡 驱 动 配置 完成 。 
重新 编译 内 核 和 模块 ， 并 将 内 核 映 像 以 及 内 核 模块 安装 到 /vita/sysroot 
目录 下 。 


6.4 局 动 udev 


前 面 我 们 将 网 卡 驱 动 编译 为 模块 ， 为 了 自动 加 载 网 卡 驱 动 ， 需 要 
启动 udev， 为 此 需要 修改 init 脚 本: 


/vita/sysroot/sbin/init: 


#!/bin/bash 
mount -oO remount,rw /dev/sda2 / 


udevd --daemon 
udevadm trigger --action=add 
udevadm settle 


export HOME=/root 
exec /bin/bash -1 


这 几 条 命令 我 们 在 讨论 initramfs 时 已 经 见 过 了 “。 事 实 上 ， 这 里 局 动 
udev 服 务 ， 不 仅 是 为 了 加 载 网 卡 驱 动 模 块 。initramfs 中 往往 只 包含 存储 
介质 相关 的 驱动 ， 而 其 他 大 量 设备 的 驱动 ， 大 部 分 还 是 保存 在 根 文件 
系统 中 ， 所 以 ， 在 挂 载 了 根 文件 系统 后 ， 需 要 重新 模拟 一 负 热 插 拔 ， 
从 根 文 件 系统 中 加 载 相关 设备 的 驱动 模块 。 


6.5 ” 安 交 网 络 配置 工具 并 配置 网 络 


在 用 户 空间 中 ， 我 们 使 用 工具 认 来 配置 网 络 ， 工 具 认 包含 在 软件 包 


iproute2 中 。 上 所 以 我 们 首 移 来 编译 安 闭 软 件 包 iproute2 。 


vita@baisheng:/vita/builds tar \ 
XVE /BOUrCe/LIDrIOUte2=3 B80 tarsx 


iproute 中 包含 很 多 网 络 管理 工具 ， 但 是 其 中 一 些 工 具 我 们 构建 的 vita 系 


统 并 不 需要 。 而 编译 这 些 不 必要 的 工具 还 需要 引入 一 些 额外 的 库 或 者 工 


具 ， 比 如 网 络 流 量 控制 工具 和 套 接 字 统计 工具 要 求 系统 安装 工具 bison 。 


此 ， 我 们 只 安装 和 网 络 配置 相关 的 工具 。 为 此 ， 在 iproute2 的 顶层 目录 下 的 
Makefile 中 ， 将 下 面 的 编译 目标 : 


SUBDIRS=1ib ip tc bridge misc netem genl man 


修改 为 : 
SUBDIRS=1ib ‘ip 
执行 如 下 命令 编译 安装 : 
vita@baisheng:/vita/build/iproute2-3.8.0$ make install 


为 了 验证 我 们 的 网 络 是 否 配 置 正确 ， 我 们 安 洲 ping 工 具 ， 该 工具 在 软件 
包 iputils 中 。 


vita@baisheng:/vita/builds tar \ 
NUE cBOUrPGeriputlileri2Z0l2T221 arbz2 


我 们 只 编译 IPv4 的 ping 工 具 ， 在 iputils 的 顶层 目录 下 的 Makefile 中 ， 将 下 
面 的 编译 目标 : 


IPV4 TARGETS=tracepath ping clockdiff rdisc arping tftpd rarpd 
IPV6 TARGETS=tracepathé6 tracerouteé6 ping6 
TARGETS=$ (IPV4 TARGETS) $ (IPV6 TARGETS) 


修改 为 : 


IPV4 TARGETS=ping 
IPV6 TARGETS=tracepathé6 tracerouteé6 Ping6 
TARGETS=$ (IPV4 TARGETS) 


我 们 构建 的 vita 系 统 中 目前 没有 安装 Capability 相 关 的 库 ， 因 此 我 们 去 掉 
ping 对 库 Capability 的 依赖 ， 我 们 也 不 需要 ping 的 这 个 特性 。 因 此 ， 在 iputils 
的 顶层 目录 下 的 Makefile 中 ， 将 下 面 的 变量 : 


USE CAP=yes 
修改 为 : 
USE CAP=no 


执行 如 下 命令 编译 安装 : 


vita@baisheng:/vita/build/iputils-s20121221$ make 
vita@baisheng:/vita/build/iputils-s20121221$ cp ping \ 
/vita/sysroot/bin/ 


更 新 vita 系 统 的 根 文 件 系 统 并 重新 启动 ， 然 后 使 用 如 下 命令 查看 网 络 接 


ip link show 


如 琳 网 卡 被 正确 驱动 了 ， 那 么 应 该 可 以 看 到 网 络 接口 。 笔 者 机 硕 的 网 
络 接口 为 eth0， 因 此 在 后 面 的 命令 中 使 用 的 是 eth0， 读 者 可 能 需要 根据 自己 
的 具体 情况 调整 。 一 般 而 言 ， 第 一 块 有 线 网 卡 接口 都 为 eth0。 


在 配置 网 络 前 ， 如 采 网 络 接口 的 状态 是 "down"， 那 么 首先 使 用 如 下 命 
令 将 网 络 接口 状态 设置 为 "up": 


ijp link set etho up 
然后 使 用 如 下 命令 设置 网 卡 的 人 P 地 址 : 


ip addr add 192.168.56.2/24 dev eth0 


具体 的 IP 地 址 需要 根据 读者 自己 的 实际 情况 调整 ， 总 之 ， 需 要 和 答 主 
系统 在 一 个 网 段 上 。 


设置 了 IP 地 址 后 ， 工 具 ip 目 动 增加 了 路 由 ， 可 以 使 用 如 下 命令 查看 : 


ip route Show 


图 6-10 是 在 笔者 构建 的 vita 系 统 上 配置 网 络 的 过 程 
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e1000 QO000:00:03.0 ethQ: IntelCR) PROZ1000 Network Connection 
cannot set terminal process group ({-1): Inappropriate ioctl] for device 

| 
root@vita:,/# 
rootBwvita:/# ip link show 

lo: <LOOPBACK> mtu 65536 gdisc noop state DOWN mode DEFAULT 

link/loopbhback O00:00:00:00:00:00 brd 0Q0:00:00:00:00:00 

cthO: <BROADCAST, MULTICAST> mtu 1500 gdisc noop state DOWN mode DEFAULT glen 

1000 

link/ether OQ8:00:27:bO:84:df brd ff :fF:ER:FR:FE:FE 
"O00tBwvita :#3 
root@vita:/# ip link set eth® up 
e1000: EthO NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx 
rootBwvita:,# 
root@vita:/# ip addr add 192.168.56.2/24 dev ethd 
root@vita:/# 
rootBvita:/# ip route Show 
192.168.56.0/24 dev eth® proto kernel scope link src 192.168.56.2 
oDtBvita:/# 
ootevitai:-# pindg 192 .168 .56 ,1 
PING 132.168.56.1 (192.168.56.1) 56(84) butes 
bp4 byutes from 192.168.56.1: icmp_ sedy=1 tt1=64 time=4.43 ms 
p4 butes from 192.168.56.1; icmp_sedq=2 ttl=6bd4 七 i Ws ms 
b4 buyutes from 192.168.56.1: icmpb_sed=3 ttl1=64 time=Q.223 ms 
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图 6-10 网 络 配置 过 程 


配置 完成 后 ， 可 以 使 用 命令 ping 确 认 网 络 是 否 已 经 成 功 配置 。 


最 后 ， 为 了 不 必 每 次 重启 系统 后 都 手动 重复 执行 这 些 网 络 配置 命令 ， 
我 们 将 其 添加 到 init 中 : 


:vita/svearoot/sbin/inits 


#!/bin/bash 
mount -o remount,rw /dev/sda2 / 


udevd --daemon 
udevadm trigger --action=add 
udevadm settle 


ip link set eth0 up 
ip addr add 192.168.56.2/24 dev eth0 


export HOME=/root 
exec /bin/bash -1 


6.6” 安 闭 并 配置 ssh 服 务 


既然 网 络 已 经 配置 好 了 ， 一 般 情 况 下 吏 不 必 再 通过 第 三 方 系统 ( 即 虚 
拟 机 ) 更 新 vita 系 统 了 ， 可 以 直接 通过 网 络 和 vita 系 统 打交道 了 。 当 然 如 果 
征 更 新 内 核 、initramfs 或 者 整个 文件 系统 ， 还 是 要 通过 虚拟 机 系统 的 。 我 们 
在 答 主 系统 和 vita 系 统 之 间 使 用 ssh 服 务 进行 通信 。 因 此 在 这 一 市 ， 我 们 为 
vita 系 统 安 逆 并 配置 sh 服务 。 


我 们 使 用 ssh 协 议 的 开源 实现 openssh， 其 依赖 zlib 和 openssl， 因 此 首先 
编译 安装 这 两 个 软件 包 。 


使 用 如 下 命令 编译 安装 zlib: 


vita@baisheng:/vita/builds tar xvf ../source/zlib-1.2.7.tar.bz2 

vita@baisheng:/vita/build/zlib-1.2.7$ ./configure --prefix=/usr 

vita@baisheng:/vita/build/zlib-1.2.7$ make 

vita@baisheng:/vita/build/zlib-1.2.7$ make install 

vita@baisheng:/vita/build/zlib-1.2.7$ find $SYSROOT -name \ 
"*.la'" -exec rm -f '{}' \; 


使 用 如 下 命令 编译 安装 openssl: 


vita@baisheng:/vita/builds tar xvf \ 
../source/openssl-1.0.1le.tar.gz 

vita@baisheng:/vita/build/openssl-1.0.les$ ./config --prefix=/usr 
--openssldir=/etc/ssl 

vita@baisheng:/vita/build/openssl-1.0.1es$ make 

vita@baisheng:/vita/build/openssl-1.0.1les make install \ 
MANDIR=/usr/share/man INSTALL PREFIX=$SYSROOT 

vita@baisheng:/vita/build/openssl-1.0.1les find $SYSROOT -name \ 
"*.la" -exec rm -f '{}' \; 


openssh 的 依赖 已 经 安装 完成 ， 下 面 安装 openssh， 命 令 如 下 : 


vita@baisheng:/vita/builds$ tar xvf ../source/openssh-6.1pl.tar.gz 
vita@baisheng:/vita/build/openssh-6.1p1l$ \ 
LD=i686-none-linux-gnu-gcc ./configure \ 
--prefix=/usr --sysconfdir=/etc/ssh \ 
--without-openssl-header-check 
vita@baisheng:/vita/build/openssh-6.1p1l$ make install \ 
DESTDIR=S$SYSROOT 


在 openssh 的 编译 脚本 中 ， 调 用 链接 絮 时 传递 了 参数 -fstack-protector- 
all。 链 接 器 不 允许 链接 可 执行 文件 时 使 用 以 "-f 开 头 的 参数 ， 以 "-f" 开 头 的 
参数 只 能 用 于 链接 动态 库 。 解 决 这 个 问题 的 方法 之 一 束 是 避免 直接 调用 链 
接 辟 进行 链接 ， 而 是 通过 gcc 间 接 调用 链接 器 。 这 就 是 在 配置 openssh 时 议定 
LD=i686-none-linux-gnu-gcc， 徐 盖 系 统 环境 变量 中 定义 的 LD=i686-none- 
linux-gnu-ldd 的 目的 。 


读者 可 能 会 有 个 疑问 ， 在 答 主 系统 上 编译 openssh 时 并 不 会 遇 到 类 似 问 
题 啊 ! 那 是 因为 在 非 交叉 编译 环境 下 ， 一 般 系 统 环境 变量 中 不 会 定义 LD， 
而 如 果 环 境 变 量 中 没有 定义 ， 那 么 openssh 的 编译 脚本 则 将 LD 定 义 为 编译 
絮 ， 从 而 绕 过 了 这 个 问题 ， 脚 本 如 下 : 


openssh-6.1pl/configure.ac: 

if test -z "$LD" ; then 
LD=S8G 

fi 


当然 读者 不 必 纠 结 这 个 问题 ， 这 仅 是 openssh 在 交叉 编译 环境 中 的 一 个 
小 插曲 而 已 。 安 钱 完 sh 后， 下 面 我 们 开始 配置 ssh 服 务 。 


openssh 文 持 一 种 安全 机 制 ， 称 为 特权 分 离 (Privilege Separation) ， 这 
个 机 制 是 默认 开局 的 。 但 是 这 个 机 制 要 求 一 些 附加 操作 ， 比 如 建立 非特 权 


用 户 等 。 为 简单 起 见 ， 我 们 关 反 了 这 个 机 制 。 


为 了 方便 ，vita 系 统 允 许 ssh 服 务 使 用 root 用 户 登 了 水。 同样 为 了 方便 ， 笔 
者 将 vita 系 统 的 root 密 码 设置 为 裤 ， 因 此 也 需要 配置 ssh 服 务 允许 登录 用 户 密 
码 为 空 。 


最 终 ，ssh 服 务 的 配置 文件 sshd_config 中 的 相关 变量 按照 如 下 进行 修 
改 : 


/vita/sysroot/etc/ssh/sshd config: 
UsePrivilegeSeparation no 


PermitRootLogin yes 
PermitEmptyPasswords yes 


除了 配置 ssh 服 务 外 ， 根 据 ssh 协 议 2.0 的 要 求 ， 还 需要 为 ssh 服 务 创建 
dsa、rsa 和 ecdsa 三 种 类 型 的 密 钥 。 而 创建 密 钥 需要 一 些 账户 信息 ， 因 此 ， 我 
们 首先 要 为 vita 系 统 添 加 账户 信息 。 


用 户 信息 保存 在 文件 /etc/passwd 中 ， 格 式 为 : 


name:password:uid:gid:comment:home:shell 


其 中 ，name 是 用 户 名 ; password 是 用 户 密码 ;uid 是 用 户 ID; gid 是 用 户 
所 属 的 组 ，comment 保 存 如 用 户 的 真实 姓名 等 一 些 信息 ;home 是 用 户 的 属 
主 目录 ; shell 是 用 户 登 录 后 执行 的 命令 。 


组 信息 保存 在 文件 /etc/group 中 ， 格 式 为 : 


group name:password:gid:user list 


其 中 ，group_name 是 组 名 ; password 是 组 的 密码 ; gid 是 组 ID; user_list 
部 分 记录 属于 该 组 的 所 有 用 户 (用 户 之 间 使 用 逗号 分 隔 ) 。 


我 们 在 vita 系 统 上 创建 的 的 具体 的 passwd 和 group 文 件 分 别 如 下 : 


/vita/sysroot/etc/passwad: 
rootss00s vr/rootsy/bin/bash 


/vita/sysroot/etc/group: 
rTOOts :0 


一 切 准 备 就 绪 后 ， 更 新 vita 的 文件 系统 。 重 局 后 ， 在 vita 系 统 上 使 用 命 
令 ssh-keygen 创 建 密 钥 ， 这 个 工具 也 是 软件 包 openssh 提 供 的 。 


在 默认 情况 下 ，dsa、rsa 和 ecdsa 分 别 存储 在 文 
件 /etc/ssh/ssh_host_dsa_key 、/etc/ssh/ssh_host_rsa_key 以 
及 /etc/ssh/ssh_host_ecdsa_key 中 ， 当 然 也 可 以 在 ssh 服 务 的 配置 文件 
sshd_config 中 修改 这 些 默 认 的 设置 。 创 建 密 钥 的 命令 分 别 如 下 : 
ssh-keygen -t dsa -f /etc/ssh/ssh host dsa key 


ssh-keygen -t rsa -f /etc/ssh/ssh host rsa key 
ssh-keygen -t ecdsa -f /etc/ssh/ssh host ecdsa key 


当 ssh-keygen 提 示 输 入 "passphrase" 时 ， 直 接 按 回 车 即 可 。 图 6-11 是 在 笔 
者 构建 的 vita 系 统 上 创建 dsa 密 钥 的 过 程 : 


11.10 [正在 运行 ] - Oracle VM VirtualBox 


e100 QO00:00:03.0 ethQ: Intel(R) PRO/1000 Network Connection 
bash: cannot set terminal process group (-1): Inappropriate ioctl for device 
bash: no job control in this shell 
root@wvita:/# 
root@vita:/# ssh-keygen -t dsa -f /etc/sshxssh_host_dsa_key 
Generating public/private dsa key pair. 
Enter passphrase (empty for no passphrase}: 
Enter same passphrase again: 
Your identification has been saved in /etc/ssh/ssh host dsa_key. 
four public key has been saved in /etc/ssh/ssh_host_dsa_key .pub. 
The key fingerprint is: 
B22:ec:d3:934:5b:7?f :7?79:f2:39:1d:61:19:b6:1d:7?8:50 roote (none) 
The key’s randomart image is: 
4 一 一 [ 了 SR 1LGZ4] 一 一 一 一 上 
! .+Eo! 
上 .DO= | 

0 00.1 


四 上 邹 各 于 多 贺 右 ctrl 


图 6-11 创建 dsa 密 钥 
其 他 两 个 密 钥 rsa 和 ecdsa 按 照 dsa 的 创建 如 法 炮制 即 可 。 


密 钥 创建 一 次 即 永久 保存 在 文件 系统 了 ， 如 果 删 除了 vita 系 统 的 根 文件 
系统 ， 需 要 再 次 重新 创建 这 几 个 密 钥 。 


从 答 主 系统 远程 登录 vita 系 统 时 ，vita 系 统 需 要 为 登录 的 用 户 分 配 盆 终 
端 (PTY) ， 而 伪 终 端 设备 世 点 建立 在 /dev/pts 目 孙 下 ， 并 且 /devwpts 要 求 挂 
载 devpts 文 件 系统 。 如 果 没 有 挂 载 devpts, 登 录 将 失败 ， 报 错 信息 类 似 如 下 : 


PTY allocation request failed on channel 0 


为 此 ， 修 改 init 程 序 ， 挂 载 devpts， 方 法 如 下 : 


/vita/sysroot/sbin/init: 


#!/bin/bash 
mount -o remount,rw /dev/sda2 / 


udevd --daemon 
udevadm trigger --action=add 


udevadm settle 


ip link set etho up 
ip addr add 192.168.56.2/24 dev etho 


mkdir /dev/pts 
mount -n -t devpts devpts /dev/pts 


export HOME=/root 
exec /bin/bash -1 


一 切 束 绕 ， 在 vita 系 统 局 动 时 ， 歌 认 局 动 ssh 服 务 : 


/vita/sviroot/ ebDin nit: 


#!/bin/bash 
mount -Oo remount,rw /dev/sda2 / 


udevd --daemon 
udevadm trigger --action=add 
udevadm settle 


ip link set eth0 up 
ip addr add 192.168.56.2/24 dev etho 


mkdir /dev/pts 
mount -n -t devpts devpts /dev/pts 


/usr/sbin/sshd 


export HOME=/root 
exec /bin/bash -1 


更 新 vita 系 统 的 init 程 序 ， 重 启 后 ， 就 可 以 顺利 地 从 窒 主 系统 登录 全 |vita 
系统 了 。 一 旦 可 以 远程 登录 到 vita， 工 作 的 效率 就 会 大 大 提高 ， 我 们 可 以 使 
用 窒 主 系统 的 强大 的 终端 。 而 且 ， 更 重要 的 一 点 十， 除非 对 根 文 件 系 统 进 


行 彻 底 的 更 新 ， 或 者 更 新 内 核 ， 否 则 不 再 需要 频繁 地 重启 系统 。 


6.7” 安 逆 procps 


为 了 方便 后 面 调试 ， 我 们 在 vita 系 统 上 安装 procps。 该 软件 包 中 包含 了 
常用 的 一 些 工 具 ， 如 ps、Kill 等 。 因 为 vita 系 统 中 没有 安装 ncurses 库 ， 为 简单 
起 见 ， 我 们 只 编译 不 需要 使 用 ncurses 库 绘制 界面 的 程序 ， 这 就 是 编译 procps 
时 传递 参数 "--without-ncurses" 的 目的 。 


vita@baisheng:/vita/builds tar \ 


XVvf ../source/procps-ng-3.3.6.tar.xz 
vita@baisheng:/vita/build/procps-ng-3.3.6$ ./configure \ 
--prefix=/ --without-ncurses 


vita@baisheng:/vita/build/procps-ng-3.3.6$ make 
vita@baisheng:/vita/build/procps-ng-3.3.6$ make install 


6.8 ”安装 X 窗 口 系统 


UNIX 系 统 的 主要 目标 号 古 多 用 户 、 多 任务 ， 而 且 人 允许 多 个 用 户 远 程 登 
孙 并 发 执行 任务 。 这 种 设计 哲学 同样 被 达到 了 X 窗 口 系统 中 。X 的 实现 者 将 
X 设 计 为 客户 /服务 器 的 架构 ， 应 用 程序 相当 于 客户 端 ， 它 们 不 需要 关心 具 
体 的 显示 和 用 户 输 入 ， 而 由 X 服 务 右 人 负 员 管理 显示 设备 和 输入 设备 。 应 用 程 
序 只 需要 将 请 求 ， 比 如 “绘制 一 条 直线 从 点 A 到 点 B”"， 发 送 给 X 服 务 器 ， 而 
由 X 服 务 器 负 员 将 其 绘制 到 具体 的 显示 设备 上 。X 服 务 器 也 会 将 用 户 的 输入 
(包括 鼠标 、 键 盘 等 输入 事件 ) ， 转 发 给 对 应 的 应 用 。 


X 将 协议 相关 实现 封 狠 到 了 一 个 库 中 ， 开 发 者 将 这 个 库 称 为 Xlib。 后 来 
因为 效率 问题 ， 又 开发 了 xcb 来 奉 代 Xlib。Xlib 中 封装 的 只 是 X 的 核心 协议 ， 
X 使 用 扩展 的 方式 扩充 X 协 议 ， 其 他 扩展 协议 可 以 在 单独 的 库 中 实现 。 


作为 类 UNIX 的 图 形 系统 的 基础 ，X 的 复杂 是 难以 避免 的 。 也 恰恰 是 因 
为 X 的 复杂 ， 很 多 人 提 及 X 的 安装 就 会 谈 虎 色 变 。 虽 然 X 系 统 非常 庞大 ， 实 
际 上 它 也 是 有 章 可 循 的 。 本 节 笔 者 就 带领 读者 从 头 安装 一 个 X 窗 口 系统 。 鉴 
于 X 的 安装 过 程 比 较 烦 琐 和 复杂 ， 我 们 提供 了 一 个 安装 脚本 build-X11.sh 。 
但 是 笔者 建议 读者 尽量 使 用 手动 的 方式 安 炙 ， 这 样 可 以 在 思考 和 解决 问题 
中 不 断 提 高 。 遇 到 目 己 实在 解决 不 了 的 问题 时 再 参考 这 个 脚本 ， 从 而 达到 
更 好 的 学 习 效 果 。 


6.8.1 ”安装 M4 宏 定 义 


X 定 义 了 一 些 公 用 的 M4 安 ， 并 将 它们 放 在 软件 包 util-macros 中 。X 的 各 
个 组 件 的 配置 脚本 中 将 使 用 M4 宏 ， 因 此 我 们 首先 来 安装 M4 宏 ， 方 法 如 下 : 
vita@baisheng:/vita/builds$ tar xvf \ 
../source/X7.7/util-macros-1.,.17.tar.bz2 
vita@baisheng:/vita/build/util-macros-1.17$ ./configure \ 


--prefix=/usr 
vita@baisheng:/vita/build/util-macros-1.17$ make install 


在 第 7 章 讨论 窗口 管理 器 的 构建 脚本 时 ， 我 们 介绍 了 M4 宏 ， 读 者 可 以 
参考 那里 的 讨论 。 


6.8.2 ”安装 X 协 议和 扩展 


又 包含 了 多 种 协议 和 扩展 ， 为 简单 起 见 ，Vita 系 统 不 必 全 部 安 狼 。 比 如 
蔡 掉 了 记录 事件 的 扩展 Record， 文 持 扩 展 屏 幕 的 协议 Xinerama 及 用 于 屏保 的 
Screensaver， 禁 挥 了 已 经 过 时 的 DRI1 等 。 下 面 是 vita 系 统 安装 的 协议 ， 安 装 
这 些 协 议 时 没有 先后 顺序 要 求 。 如 果 不 要 求 X 服 务 癸 支持 DRI2， 那 么 可 以 
安装 更 少 的 协议 ， 比 如 去 掉 glproto、dri2proto、damageproto 等 。 


(1) 核心 协议 


Xlib 中 的 绝 大 部 分 编程 接口 ， 如 XCreateWindow、 XMapWindow 、 
XDrawRectange、XCopyArea 等 都 是 由 X 核 心 协 议定 义 的 。 核 心 协议 的 定义 
在 软件 包 xproto 中 。 


(2) 基本 扩展 


X 的 基本 扩展 包括 : DOUBLE-BUFFER (DBE) 、DPMS 、Extended- 
Visual-Information (EVI) 、Generic Event Extension ~ LBX、 MIT-SHM、 
MIT-SUNDRY-NONSTANDARD ~ Multi-Buffering 、 SECURITY ~、 SHAPE 、 
SYNC、TOG-CUP、XC-APPGROUP、XTEST。 它 们 的 定义 在 软件 包 


xextproto 中 


(3) 键 副 扩展 


键 弄 扩 展 定义 了 键盘 的 模型 、 布 局 ， 如 对 于 不 同 的 键盘 模型 ， 某 个 键 
值 对 应 的 字符 。 键 盘 扩 展 的 定义 在 软件 包 kbproto 中 。 


(4) 输入 扩展 


输入 扩展 是 为 一 些 特 殊 的 输入 设备 定义 的 协议 。 通 过 这 个 扩展 ， 输 入 
设备 可 以 模拟 出 与 鼠标 、 键 盘 等 核心 输入 设备 相同 格式 的 事件 。 输 入 扩展 
的 定义 在 软件 包 inputproto 中 。 


(5) XCB 协 议 


鉴于 XIlib 的 效率 ， 开 发 者 们 开发 了 更 高 效 的 XCB 来 奉 代 Xlib。XCB 协 议 
是 用 于 这 个 库 的 协议 ， 其 以 XML 形式 定义 ， 并 提供 python 程 序 将 这 些 XML 
摘 述 文件 转换 为 相应 的 程序 代码 。XCB 协 议 的 定义 在 软件 包 xcb-proto 中 。 


(6) GLX 扩 展 


GLX 扩 展 定义 了 OpenGL 和 X 之 间 通 信 的 协议 。 该 扩展 的 定义 在 软件 包 
glxproto 中 。 


(7) DRI2 扩 展 


DRI2 扩 展 是 DRI 的 第 2 个 版 本 ， 定 义 了 应 用 不 通过 X 服 务 器 直接 使 用 便 
件 进 行 泻 染 的 协议 。DRI2 扩 展 的 定义 在 软件 包 dri2proto 中 。 


(8) XFixes 扩 展 


从 这 个 扩展 的 名 字 也 可 以 看 出 ， 这 个 扩展 其 实 是 为 解决 X 核 心 协议 存在 
的 各 种 限制 的 。 该 扩展 的 定义 在 软件 包 fixesproto 中 。 


(9) Damage 扩 展 


Damage 扩 展 古 X 服 务 妖 用 来 记 杂 那些 离 屏 的 、 发 生 了 变化 的 绘制 区 域 
的 协议 。Damage 扩 展 的 定义 在 软件 包 damageproto 中 。 


(10) XC-MISC 扩 展 


应 用 可 以 通过 XC-MISC 扩 展 获 取 X 服 务 右 可 用 的 资源 ID， 如 
GetXIDRange、GetXIDList 等 。 该 扩展 的 定义 在 软件 包 xcmiscproto 中 。 


(11) BIG-REQUESTS 扩 展 


BIG-REQUESTS 扩 展 提供 了 对 大 于 262140 字 节 的 请 求 的 文 持 。 该 扩展 
的 定义 在 软件 包 bigreqsproto 中 。 


(12) RANDR 扩 展 


RANDR 扩 展 定义 了 动态 调整 屏幕 尺寸 、 旋 转 屏 幕 以 及 镜像 屏幕 的 协 
议 。X 提 供 的 工具 xrandr 束 是 这 个 协议 的 一 个 典型 使 用 者 。 该 扩展 的 定义 在 
软件 包 randrproto 中 。 


(13) RENDER 扩 展 


RENDER 扩 展 古 X 使 用 的 较 新 的 泻 染 模型 ， 用 于 合成 多 个 绘制 区 域 ， 相 
对 于 原始 的 通过 复制 进行 合成 的 模型 其 更 有 效率 。 该 扩展 的 定义 在 软件 包 


renderproto 中 。 
(14) 字体 扩展 


字体 扩展 定义 了 X 中 与 字体 处 理 相关 的 协议 。 字 体 扩展 的 定义 在 软件 包 


fontsproto 中 。 


视频 扩展 定义 了 X 的 视频 输出 相关 的 协议 。 该 扩展 的 定义 在 软件 包 


videoproto 中 。 


(16) 复合 扩展 


复合 扩展 是 为 了 X 文 持 窗 口 特效 设计 的 扩展 。 在 没有 这 个 扩展 之 前 ， 所 
有 的 在 窗口 上 的 绘制 操作 都 “实时 ”显示 在 屏幕 上 。 而 复合 扩展 允许 窗口 可 
以 先 在 离 屏 的 区 域 进行 绘制 。 复 合 扩展 的 定义 在 软件 包 compositeproto 中 。 


(17) 资源 扩展 


资源 扩展 定义 了 应 用 程序 查询 Xx 服务 句 各 种 资源 使 用 情况 的 协议 。 该 扩 
展 的 定义 在 软件 包 resourceproto 中 。 


(18) 直接 图 形 访问 扩展 


顾名思义 ， 直 接 图 形 访问 扩展 也 是 为 了 直接 访问 图 形 硬 件 设计 的 协 
议 , 不 过 其 功能 非常 有 限 ， 目 前 基本 已 经 停止 开发 ， 但 vesa 驱 动 还 在 使 用 这 
个 扩展 。 该 扩展 的 定义 在 软件 包 xf86dgaproto 中 。 


些 协 议 的 配置 安装 都 非常 简单 ， 而 且 安装 命令 完全 相同 。 以 xproto 为 


vita@baisheng:/vita/builds tar xvf \ 
/OUILECerXT /XBroEo>7: 05239Ea bz2 
vita@baisheng:/vita/build/xproto-7.0.23$ ./configure \ 
--prefix=/usr 
vita@baisheng:/vita/build/xproto-7.0.23$ make install 


6.8.3 ”安装 X 相 关 库 和 工具 


在 安装 X 服 务 器 前 ， 我 们 需要 安装 X 服 务 器 依赖 的 库 、 这 些 库 依 赖 的 库 
以 及 X 服 务 器 使 用 的 工具 和 相关 数据 。 注 意 ， 某 些 库 是 有 安装 顺序 要 求 的 ， 
比如 ，libX11 需 要 在 libxkbfile 前 安装 ， 安 闭 jibXfont 半 需要 和 匈 安装 freetype， 
libdrm、expat 需 要 在 Mesa 前 安装 等 。 读 者 按照 下 面 的 顺序 安装 即 可 


(1) pixman 


pixman 是 一 个 底层 的 像素 操作 的 库 ， 提 供 独 形 合成 及 光栅 化 等 功能 
征 X 中 软件 浑 染 的 基础 。 


(2) xtrans 


xtrans 封 效 了 网 络 传输 的 基本 功能 ， 从 开发 角度 讲 ， 征 X 服 务 硼 和 应 用 
程序 之 间 进 行 通 信 的 基础 。X 服 务 器 、libX11 等 X 的 相关 组 件 都 要 用 到 这 个 
库 。 


(3) libXau 


libXau 征 又 服 务 器 和 应 用 程序 之 间 认 证 授权 使 用 的 库 。 


(4) libX11 、 libxcb 和 和 libpthread-stubs 


libX11 是 为 应 用 程序 提供 的 X 协 议 的 实现 ， 应 用 程序 使 用 libX11 中 提供 


的 API 和 X 服 务 怖 进行 通信 。 


因为 libX11 的 效率 问题 ， 开 发 人 员 又 开发 了 libxcb 来 奉 换 libX11。 而 反 
过 来 ，libX11 也 基于 xcb 进 行 了 改进 ， 所 以 在 安装 libX11 前 ， 需 要 安装 
libxcb ° 


libxcb 依 赖 libpthread-stubs， 因 此 在 安装 libxcb 前 需要 先 安装 libpthread- 


stubs ° 


(5) libxkbfile、xkbcomp 和 xkeyboard-config 


这 三 个 包 都 与 键盘 扩展 相关 。X 服 务 器 根据 键盘 扩展 ， 确 定 不 同 键盘 模 
型 的 键盘 的 布局 、 键 值 到 字符 的 转换 等 。 键 盘 相关 的 数据 就 包含 在 
Xkeyboard-config 中 。 


而 开发 者 将 操作 这 些 数据 的 功能 封闭 在 库 libxkbfile 中 。 


xkbcomp 包 中 提供 了 同名 的 工具 xkbcomp， 该 工具 根据 键盘 映射 的 摘 
述 ， 将 键盘 映射 编译 为 X 服 务 器 可 以 识别 的 指定 格式 。 


(6) libXfont 、 libfontenc 和 freetype 


这 几 个 库 都 是 与 字体 处 理 相 关 的 。 开 发 者 将 X 使 用 的 与 字体 相关 的 功能 
封装 在 库 libXfont 中 。 


而 libXfont 使 用 freetype 进 行 字体 泻 染 ， 使 用 libfontenc 处 理 字 体 编码 。 所 
以 安装 libXfont 前 需要 安装 libfontenc 和 freetype 。 


(7) pciaccess 


早期 版 本 的 GPU 的 2D 驱 动 ， 包 括 X 服 务 器 中 的 一 些 功 能 ， 不 通过 内 
核 ， 而 十 直接 访问 PCI 接 口 的 GPU， 这 束 是 这 个 库 的 由 来 。 现 在 虽然 GPU 驱 
动 都 通过 内 核 访 问 GPU 硬 件 了 ， 但 是 xX 服务 器 中 并 没有 清理 得 特别 干净 ， 还 
残存 着 对 pciaccess 库 的 依赖 。 


库 libdrm 中 也 使 用 了 部 分 pciaccess 中 的 功能 。 比 如 通过 读 取 PCI 寄 存 属 
探测 BIOS 中 给 GPU 分 配 的 显存 大 小 ，libdrm 借 助 的 就 是 库 pciaccess 中 的 函 
尖 O 


(8) libdrm 


用 户 空间 的 组 件 ， 如 GPU 的 2D 驱 动 和 3D 驱 动 、GLX 扩 展 (包括 X 服 务 
器 端 和 Mesa 端 的 实现 部 分 ) 等 ， 都 需要 通过 内 核 的 DRM 模 块 访问 GPU“。 为 
了 方便 用 户 空间 的 组 件 访问 内 核 DRM 模 块 ， 开 发 者 开发 了 库 libdrm 。 


(9) Mesa、expat、1libXext、libXdamage 和 1libXfixes 


如 采 配 置 X 服 务 器 文 持 DRI2， 那 么 必须 要 安装 Mesa， 它 是 3D 应 用 程序 
进行 直接 演 染 的 基础 。 


Mesa 中 的 DRI 扩 展 使 用 Damage 扩 展 告知 X 服 务 器 绘制 完成 ， 因 此 需要 
安装 libXdamage 。 


Mesa 中 的 DRI2 扩 展 使 用 XFixes 扩 展 中 的 如 XFixesCreateRegion 创 建 发 生 
了 改变 的 区 域 ， 也 就 是 绘制 发 生 的 区 域 ， 因 此 也 需要 安装 库 libXfixes。 


而 在 安装 扩展 前 ， 需 要 安装 库 JibXext。 它 是 所 有 扩展 的 公共 库 。 


另外 ，Mesa 使 用 expat 解 析 XML ， 所 以 安装 Mesa 前 ， 还 需要 安装 


expat ° 


在 安装 上 述 相关 库 之 前 ， 在 宿主 系统 上 还 需 安装 几 个 辅助 的 软件 包 。 
一 个 是 xkeyboard-config 依 赖 的 intltool。 男 外 是 Mesa 依 赖 的 xutils-dev、flex 和 
bison， 使 用 如 下 命令 在 宿主 系统 上 安装 这 几 个 软件 包 : 


root@baisheng:~# apt-get install intltool 
root@baisheng:~# apt-get install xutils-dev 
root@baisheng:~# apt-get install flex 
root@baisheng:~# apt-get install bison 


除了 Mesa 外 ， 这 些 库 的 安装 完全 相同 。 以 pixman 为 例 ， 配 置 及 安装 命 
令 如 下 : 


vita@baisheng:/vita/builds tar xvf ../source/pixman-0.28.0.tar.gz 

vita@baisheng:/vita/build/pixman-0.28.0$ ./configure \ 
--prefix=/usr 

vita@baisheng:/vita/build/pixman-0.28.0$ make 

vita@baisheng:/vita/build/pixman-0.28.0$ make install 


Mesa 的 配置 要 稍 复杂 一 点 ， 配 置 命令 如 下 : 


vita@baisheng:/vita/build/Mesa-8.0.3$ ./configure --prefix=/usr \ 
--with-dri-drivers=swrast,1i915,1i965 \ 
--disable-gallium-llvm --without-gallium-drivers 


因为 笔者 的 测试 机 器 使 用 的 是 Intel 的 GPU， 因 此 为 了 简单 ， 这 里 仅 编 译 
了 Intel GPU 的 3D 驱 动 ， 而 且 使 用 经 典 模式 的 3D 驱 动 ， 不 使 用 Gallium3D 模 
式 的 驱动 。 


男 外 ， 我 们 不 使 用 libtool 查 找 依赖 库 ， 因 此 每 次 安装 完 库 后 ， 切 记 使 用 
如 下 命令 删除 la 文件 ， 以 避免 libtool 市 来 麻烦 : 


find $SYSROOT -name "x.1an -exec rm -f '{}' \; 


6.8.4 ”安装 又 服务 需 


万 事 俱 备 ， 现 在 我 们 开始 安装 X 服 务 器 ， 配 置 及 安装 命令 如 下 : 


vita@baisheng:/vita/builds tar \ 


xXxvf ../source/X7.7/xorg-server-1.12.2.tar.bz2 
vita@baisheng:/vita/build/xorg-server-1.12.2$ ./configure \ 
--prefix=/usr --enable-dri2 --disable-dri --disable-xnest \ 
--disable-xephyr --disable-xvfb --disable-record \ 
--disable-xinerama --disable-screensaver \ 


--with-xkb-output=/var/lib/xkb --with-log-dir=/var/log 
vita@baisheng:/vita/build/xorg-server-1.12.2$ make 
vita@baisheng:/vita/build/xorg-server-1.12.2$ find $SYSROOT \\ 

-name "*.]la'" -exec rm -f '{}' \; 


各 项 配置 参数 意义 如 下 。 


人 --enable-dri2、--disable-dri: 支持 DRI2 扩 展 ， 不 支持 已 经 过 时 的 DRI1 
扩展 。 


@ --disable-xnest、--disable-xephyr、--disable-xvfb: 我 们 不 需要 模拟 的 
x 服 务 器 Xnest、Xephyr 和 Xvfb， 所 以 没有 必要 浪费 时 间 编 译 它们 。 


S --disable-record、--disable-xinerama、--disable-screensaver: 为 简单 起 


见 ， 我 们 不 使 用 X 服 务 器 的 这 几 个 特性 。 


@ --with-xkb-output=/var/lib/xkb: 指定 工 具 xkbcomp 编 译 的 键盘 映 射 文 
件 存 放 在 /var/lib/xkb 目 录 下 。 


令 --with-log-dir=/var/log: 指定 X 服 务 器 将 日 志文 件 保 存在 /var/log 目 隶 
i 


6.8.5 “安装 GPU 的 2D 张 动 


如 有 果 只 是 在 虚拟 机 上 运行 目标 系统 ， 安 装 vesa 驱 动 即 可 ， 安 装 命令 如 
下 : 


vita@baisheng:/vita/builds tar xvf \ 
../source/X7.7/xf86-video-vesa-2.3.1.tar.bz2 
vita@baisheng:/vita/build/xf86-video-vesa-2.3.1$ ./configure \ 
--prefix=/usr 
vita@baisheng:/vita/build/xf86-video-vesa-2.3.1$ make 
vita@baisheng:/vita/build/xf86-video-vesa-2.3.1$ make install 


但 是 如 果 是 在 真实 的 机 器 上 运行 目标 系统 ， 最 好 安装 相应 GPU 的 2D 驱 
动 。 在 安装 脚本 build-X11.sh 中 ， 包 含 了 安装 Intel GPU 的 2D 驱 动 的 方法 ， 恋 
者 如 果 需 要 ， 可 以 参考 。PC 上 使 用 的 GPU 一 般 都 符合 VESA 标 准 ， 所 以 在 通 
常情 况 下 ， 用 vesa 也 能 勉强 驱动 ， 但 是 vesa 驱 动 很 多 特性 不 支持 ， 比 如 硬件 
加 速 。 


6.8.6” 安 痛 X 的 输入 设备 弛 动 


看 到 输入 设备 驱动 ， 读 者 可 能 会 有 个 疑问 :内核 中 不 是 包括 了 各 种 设 
备 的 张 动 吗 ? 怎么 X 中 还 要 安 狠 设备 驱动 ? 没 错 ， 输 入 设备 的 驱动 是 在 内 核 
中 ，X 中 的 所 谓 输入 设备 的 驱动 evdev 谈 不 上 是 一 个 驱动 了 ， 只 不 过 大 家 习 
惯 这 么 称呼 而 已 。evdev 模 块 并 不 面向 任何 具体 输入 设备 ， 它 只 不 过 是 接收 
和 解析 内 核发 送 到 用 户 空 间 的 输入 事件 。 仔 细 观 察 图 6-12 所 示 的 Linux 输 入 
子 系统 的 架构 ， 读 者 目 然 束 会 明日 。 


Input Device | [EE prver| Input Core Event Handler | evdev 


Hardware | Kernel | X Server 


图 6-12 Linux 输 入 子 系 统 架 构 


| 


操作 系统 将 面 对 各 种 各 样 的 输入 设备 ， 如 鼠标 、 键 盘 、 和 触摸屏 、 游 戏 
手柄 等 。 由 于 这 些 输入 设备 大 部 分 不 遵循 统一 的 标准 ， 所 以 导致 应 用 程 
序 ， 比 如 X 将 不 得 不 处 理 来 自 各 种 输入 设备 的 五 花 八 门 的 输入 事件 。 


因此 ， 内 核 中 抽象 了 一 个 输入 子 系统 。 在 输入 子 系统 中 ， 设 备 驱 动 面 
对 各 种 各 样 具体 的 硬件 设备 ， 而 输入 事件 经 过 事件 处 理 模 块 处 理 后 ， 将 以 
统一 的 格式 发 送 给 用 户 空间 的 应 用 ， 用 户 空 间 的 应 用 无 需 再 为 各 种 各 样 的 
输入 事件 格式 疲于奔命 。 


现在 很 多 输入 设备 都 使 用 USB 接 口 ， 对 于 USB 接 口 的 输入 设备 ， 图 6-12 
演化 为 图 6-13 所 示 。 


USB Host | ; LE 


HH 和 | (Host Controller 上 加 | 


后 USB HID Input | 、 Event 
Input Device Controller | ; 


Driver [| Core Handler 


evdev 
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Hardware : Kernel : X Server 


图 6-13 Linux USB 设 备 的 输入 子 系统 架构 


USB 设 备 通过 主 控制 器 连接 到 主机 ， 所 以 内 核 需 要 驱动 USB 主 控制 
器 。USB 流 行 的 一 个 主要 原因 就 是 具有 统一 的 标准 ， 所 以 对 于 USB 接 口 的 
输入 设备 ， 它 们 使 用 统一 的 设备 驱动 ， 即 图 6-13 中 的 USB HID 弛 动 。 


通过 上 面 的 讨论 可 见 ， 从 操作 系统 的 角度 ， 安 装 X 的 输入 设备 驱动 事实 
上 有 两 件 事 需要 做 : 一 是 需要 配置 内 核 的 输入 设备 相关 的 驱动 和 模块 ， 二 
是 安装 X 的 evdev 模 块 。 


1. 配 置 内 核 输入 子 系统 相关 驱动 


如 前 文 所 说 ， 现 在 大 部 分 鼠标 、 键 盘 等 输入 设备 都 使 用 USB 接 口 ， 所 
以 这 一 节 我 们 以 USB 接 口 的 输入 设备 为 例 ， 来 配置 内 核 中 的 输入 设备 相关 
的 驱动 和 模块 。 包 括 配置 USB 总 线 及 控制 邵 的 驱动 、USB 输 入 设备 的 驱动 
以 及 事件 处 理 模块 。 


(1) 配置 USB 总 线 以 及 USB 主 控制 器 驱动 


配置 USB 总 线 及 USB 主 控制 器 驱动 的 步 又 如 下 : 


面 。 


面 。 


1) 执行 make menuconfig， 出 现 如 图 6-14 所 示 的 界面 。 


日 evice Drivers --->| 


pe 
' 


图 6-14 配置 USB 总 线 及 USB 主 控制 器 驱动 (1) 


2) 在 图 6-14 中 ， 选 择 菜 单项 "Device Drivers"， 出 现 如 图 6-15 所 示 的 界 


| 


[Bl uss support ~ 


Lm 


图 6-15 ”配置 USB 总 线 及 USB 主 控制 器 驱动 (2) 


3) 在 图 6-15 中 ， 选 中 菜单 项 "USB support"， 出 现 如 图 6-16 所 示 的 界 


--- USB support 
<*> Suypport for Host-side USB 
Eg USB verbose debug messages (NEW) 
[ ] USB announce new devices (NEW) 
*** Miscellaneous USB options *** 
[ ] Dynamic USB minor allocation (NEW) 
< > USB Monitor (NEW) 
<> Support WUSB Cable Based Association (CBA) (NEW) 
*# USB Host Controller Drivers *x* 
< > Cypress C67x890 HCD support (NEW) 
<#> xHCI HCD (USB 3.0) support 
[ ] Debugging for the xHCI host controller (NEW ) 
<*> EHCI HCD (USB 2.0) support 
[] Root Hub Transaction Translators (NEW) 
[*] Improved Transaction TransLator scheduling (NEW) 
< > OXU210HP HCD support (NEW) 
< > ISP116X HCD support (NEW) 
< > ISsP 1760 HCD support (NEW) 
<> ISP1362 HCD support (NEW) 
<*> OHCI HCD support 
[ Ceneric OHCI driver for a platform device (NEW) 
Generic EHCI driver for a platform device (NEW) 
b. UHCI HCD (most Intel and VIA 


图 6-16 ”配置 USB 总 线 及 USB 主 控制 器 驱动 (3) 


4) 在 图 6-16 中 ， 选 中 "Support for Host-side USB"， 并 分 别 选 中 几 个 典 
型 的 USB 主 控制 器 的 驱动 ， 包 括 "xHCI HCD(USB 3.0)support"、"EHCI 
HCD(USB 2.0)support" ~、 "OHCI HCD support" ~ "UHCI HCD(most Intel and 
VIA)support"。USB 总 线 及 主 控制 右 张 动 配置 完成 。 


(2) 配置 USB 输 入 设备 驱动 


在 配置 了 内 核 文 持 USB 总 线 和 主 控制 器 之 后 ， 一 般 内 核 都 会 自动 配置 
支持 USB HID 设 备 ， 至 少 我 们 使 用 的 3.7.4 版 本 的 内 核 是 这 样 的 。 如 果 读 者 
使 用 了 其 他 版 本 内 核 ， 请 自己 确认 ， 配 置 过 程 为 ， 首先 进入 "Device 
Drivers" 界 面 ， 然 后 再 进入 "HID support" 界 面 ， 查 看 USB HID 是 否 已 经 被 选 
中 ， 一 般 情况 下 选中 "Generic HID driver" 即 可 。 


(3) 配置 事件 处 理 模 块 


1) 执行 make menuconfig， 出 现 如 图 6-17 所 示 的 界面 。 


Executable file formats / Emulations ---> 
Networking Support 


Device Drivers ---> 
Firmware Drivers ---> 


图 6-17 配置 事件 处 理 模 块 (1) 


2) 在 图 6-17 中 ， 选 择 菜 单项 "Device Drivers"， 出 现 如 图 6-18 所 示 的 界 
面 0 


二 


Network device support 
Imput device suUpport ---> 


Character devices  ---> 


图 6-18 配置 事件 处 理 模 块 (2) 


3) 在 图 6-18 中 ， 选 择 菜 单项 "Input device support"， 出 现 如 图 6-19 所 示 
的 界面 。 


< > Joystick interface 
Event tnterface 
< > Event debugging 

去 二 而 IJNnput Device Drivers **t 


图 6-19 配置 事件 处 理 模块 (3) 
4) 在 图 6-19 中 ， 选 中 "Event interface"， 事 件 处 理 模块 配置 完成 。 


Linux 系 统 运 行 时 ， 事 件 处 理 模 块 将 为 输入 设备 在 /dev/input 目 录 下 建立 
相应 的 节点 ， 一 般 形 如 eventX， 其 中 "X" 是 具体 的 数字 。 在 调试 X 的 鼠标 、 
键盘 、 触 摸 屏 等 输入 设备 的 驱动 时 ， 一 旦 遇 到 麻烦 ， 可 以 先 确 认 内 核 中 的 
设备 驱动 和 事件 处 理 模 块 是 否 已 经 正确 工作 。 方 法 之 一 就 是 通过 直接 读 取 
这 些 输入 设备 的 节点 ， 命 令 如 下 (其 中 "X" 根 据 具体 的 情况 进行 替换 ) : 


cat /dev/input/eventxXx 


然后 操作 鼠标 或 者 键盘 等 输入 设备 ， 通 过 观察 是 否 有 数据 输出 ， 以 确 


yn 


认 内 核 的 输入 子 系统 部 分 是 否 已 经 正确 工作 。 


2. 安 装 evdev 模 块 
使 用 如 下 命令 安装 X 服 务 器 使 用 的 evdev 模 块 : 


vita@baisheng:/vita/builds tar xvf \ 
../source/X7.7/xf86-input-evdev-2.7.0.tar.bz2 

vita@baisheng:/vita/build/xf86-input-evdev-2.7.0$ ./configure \ 
--prefix=/usr 

vita@baisheng:/vita/build/xf86-input-evdev-2.7.0$ make install 


X 服 务 器 将 建立 一 个 套 接 字 与 应 用 程序 进行 通信 ， 通 常 这 个 套 接 字 被 命 
名 为 tmp/.X11-unix/X0"，0 表 示 是 第 一 个 X 服 务 器 ， 如 果 再 启动 第 二 个 X 服 
务 右 ， 则 为 "/tmp/.X11-unix/X1"。 除 了 建立 套 接 字 外 ，X 服 务 器 还 将 在 /tmp 
目录 下 建立 一 个 锁 文 件 ， 例 如 对 于 第 一 个 X 服 务 器 ， 这 个 锁 文 件 
为 tmp/.X0-lock"。 另 外 ， 在 前 面 编译 时 ， 我 们 指定 X 服 务 器 将 日 志文 件 存 
放 在 /var/log 目 录 下 ， 因 此 ， 我 们 需要 在 根 文件 系统 中 建立 这 两 个 目录 : 


vita@baisheng:/vita/rootfs$ mkdir -p tmp var/log 


为 了 使 书 中 的 截图 不 至 于 尺寸 过 大 ， 笔 者 将 vita 系 统 的 X 服 务 絮 的 分 辨 
率 设 置 为 “<640x480”。 最初，X 服 务 句 完全 由 用 户 通 过 书写 配置 文件 的 方式 
手动 配置 ， 在 udev 出 现 后 ，X 服 务 句 采用 了 目 动 配置 技术 。 但 是 X 也 给 用 户 
留 有 机 会 进行 手动 微调 ， 并 且 用 户 手动 配置 的 优先 级 还 要 更 高 。 当 然 读者 
不 必 设 置 分 辨 率 ， 由 X 服 务 右 目 动 探测 即 可 。 通 过 xorg.conf 设 定 分 辩 率 的 方 
法 如 下 : 


/vita/sysroot/etc/X11/xorg.conf: 


Section "Screen" 
Identifier "Screen0'" 
SubSection "Display" 

modes "640x480" 
EndSubSection 
EndSection 


最 初 ，X 服 务 闫 局 动 后 将 创建 并 显示 鼠标 指针 。 后 来 ，X 的 开发 人 员 认 
为 只 有 在 应 用 程序 明确 表明 需要 与 用 户 进行 交互 时 ， 才 应 该 显示 鼠标 指 
针 。 所 以 ， 这 个 默认 行为 发 生 了 改变 ， 在 X 服 务 紫 局 动 后 ， 不 再 默认 创建 并 
显示 鼠标 指针 ， 而 十 在 第 一 个 应 用 明确 调用 类 似 XDefineCursor 这 样 的 落 数 


请 求 X 服 务 套 显示 鼠标 后 ， 才 显示 鼠标 指针 。 


但 是 X 还 是 为 用 户 留 了 余地 ， 增 加 了 一 个 命令 行 参数 "-retro"。 如 采用 户 


运行 X 服 务 右 启动 时 即 创建 和 显示 鼠标 ， 那 么 给 X 服 务 右 传递 这 个 参数 即 


六 


也 


在 默认 情况 下 ， 当 最 后 一 个 X 应 用 断 开 与 X 服 务 怖 的 连接 后 ，X 服 务 需 
默认 目 动 重 置 。 同 样 ，X 也 为 这 个 行为 提供 了 修正 的 机 会 ， 用 户 可 以 使 用 命 
令 行 参数 "-noreset" 关 闭 这 个 特性 。vita 系 统 不 需要 这 个 特性 ， 因 此 我 们 传递 


了 "-noreset" 参 数 给 X 服 务 器 。 


最 后 ， 使 用 如 下 命令 运行 X 服 务 需 : 


root@vita:~# Xorg -retro -noreset & 


在 X 服 务 句 局 动 成 功 后 ， 将 创建 一 个 根 窗口 ， 作 为 未 来 所 有 用 户 窗 口 的 
根 。 默 认 情 况 下 ， 这 个 根 窗口 只 以 一 个 简单 的 灰色 至 景 显示 。 并 且 我 们 看 
到 ，X 也 按照 我 们 的 要 求 ， 创 建 并 显示 了 鼠标 指针 ， 如 岁 6-20 所 示 。 
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外 时 少 闻 图 右 ctrl 


图 6-20 XX 服务 絮 成 功 启 动 


6.8.8 一 个 简单 的 X 程 序 


我 们 使 用 Xlib 编 写 一 个 简单 的 X 程 序 来 确认 XX 服务 器 是 否 已 经 正常 工 
作 。 这 个 程序 非常 简单 ， 就 是 创建 一 个 窗口 ， 并 在 其 上 显示 字符 串 "Hello X 
Window!"， 代 码 如 下 : 


/vita/build/hello x/hello x.c: 


#include <X1L1/X1ib.h> 
#include <X11/Xatom.h> 
#include <stdio.h> 
#include <string.h> 


int main(int argc, char *argv[]) 


{ 


Display *dpy; 

int screen num; 

Window win; 

nt Kw， 

unsigned int w, h; 

Atom atom win type, atom win type normal; 
XEvent e; 

GC ge; 

char *s = "Hello X Window !"; 


if (!(dpy = XOpenDisplay (NULL))) { 
fprintf (stderr, "Can't connect to X sever!\n'"); 
return =1’; 


screen num = DefaultScreen(dpy); 

xX= Y= 20; 

DisplayWidth(dpy, screen num) / 2; 
DisplayHeight (dpy, screen num) / 2; 


5 
| 


win = XCreateSimpleWindow (dpy, DefaultRootWindow (dpy), 


Xi Y: Wi hy 2; BlackPixel (dpy, screen mum) ， 
WhitePixel (dpy, screen num) ) ; 


XStoreName (dpy, win, "Hello X11") ， 


atom win type = XInternAtom(dpy, "_ NET WM WINDOW TYPE", 


False); 
atom win type normal = XInternAtom(dpy, 
"_NET WM WINDOW TYPE NORMAL", False); 
XChangeProperty (dpy, win, atom win type, XA ATOM, 
32, PropModeReplace, 
(unsigned char *)&atom win type normal, 


XSelectInput (dpy, win, ExposureMask),，; 
gc = XCreateGC (dpy, win, 0, 0); 
XMapWindow (dpy, win); 


while (1) { 
XNextEvent (dpy, &e); 


光志 : 


switch (e.type) { 
case Expose: 
XDrawSstring (dp Wins ge 30 305 Bs Strlen(e)); 
break; 


编译 这 个 程序 的 Makefile 如 下 : 


/vita/build/hello x/Makefile: 
LDFLAGS= pkg-config --libs X1L1 
hello x: hello x.o 


clean: 
rm srt hello x Pe 


名 


编译 后 通过 scp 命 令 将 hello_x 复 制 到 vita 系 统 ， 并 通过 ssh 登 录 到 vita 系 
统 ， 相 应 命令 如 下 : 
vita@baisheng:/vita/build/hello xs scp hello x \ 
root@192.168.56.2:/root/ 
root@baisheng:~# ssh 192.168.56.2 
在 登录 到 vita 的 终端 中 ， 使 用 如 下 命令 启动 X 服 务 器 ， 并 运行 应 用 程序 
hello x: 
root@vita:~# Xorg -retro & 


root@vita:~# export DISPLAY=:0.0 
root@vita:~# ./hello x & 


注意 环境 变量 DISPLAY 的 设置 ， 其 格式 如 下 : 


hostname: displaynumber.screennumber 


如 果 主 机 名 (hostname) 为 空 ， 则 表示 X 服 务 器 运行 在 本 机 。 读 者 可 以 
把 display 理 解 为 一 个 X 服 务 器 ，screen 这 里 无 须 解 释 。displaynumber 和 
screennumber 均 从 0 开始 计数 ， 如 值 为 “:0.0” 表 示 运 行 在 本 机 的 第 一 个 X 服 务 
需 接 的 第 一 块 屏 幕 。vita 系 统 只 局 动 了 一 个 X 服 务 硕 ， 并 且 只 搂 一 块 屏 。 所 
以 自然 将 环境 变量 DISPLAY 设 置 为 “:0.0”。 


如 果 一 切 正常 ， 则 应 用 程序 运行 情况 如 图 6-21 所 示 。 
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Hello X llindow ! 


图 6-21 一 个 简单 的 使 用 Xlib 编 写 的 程序 


6.8.9 配置 内 核 文 择 DRM 


如 果 读 者 是 在 真实 机 器 上 调试 的 ， 那 么 为 了 使 GPU 的 2D 驱 动 和 3D 驱 动 
都 可 以 正常 工作 ， 内 核 中 还 需要 进行 相关 的 配置 ， 因 为 用 户 空间 的 GPU 驱 
动 是 通过 内 核 中 的 DRM 访 问 GPU 的 。GPU 用 户 空间 的 驱动 (2D 和 3D 了 驱动 ) 
和 内 核 空 间 的 驱动 (DRM 模块 ; 之 间 的 关系 如 图 6-22 所 示 。 
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图 6-22 ”GPU 驱动 各 部 分 间 的 关系 


在 本 节 中 ， 我 们 以 Intel 的 GPU 为 例 来 讨论 内 核 中 关于 GPU 的 相关 配置 。 
Intel 的 GPU 使 用 了 AGP 局 部 总 线 ， 所 以 在 配置 GPU 的 DRM 模 块 前 ， 需 要 首 
先 配置 内 核 文 持 AGP 总 线 。 


(1) 配置 AGP 总 线 
配置 AGP 总 线 的 步骤 如 下 : 


1) 执行 make menuconfig， 出 现 如 图 6-23 所 示 的 界面 。 


Device Dr Drivers 2 - ->| 


图 6-23 配置 AGP 总 线 (1) 


2) 在 图 6-23 中 ， 选 择 "Device Drivers"， 出 现 如 图 6-24 所 示 的 界面 。 


raphtcs support -> RE 


HI 


图 6-24 配置 AGP 总 线 (2) 


3) 在 图 6-24 中 ， 选 择 "Graphics support"， 出 现 如 图 6-25 所 示 的 界面 。 
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图 6-25 配置 AGP 总 线 (3) 


4) 在 图 6-25 中 ， 选 中 "/dev/agpgart(AGP Support)"， 出 现 如 图 6-26 所 示 
的 界面 。 
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图 6-26 配置 AGP (4) 


5) 在 图 6-26 中 ， 选 中 "Intel 440LX/BX/GX,I8xx and E7x05 chipset 
support"。AGP 总 线 配置 完毕 。 


(2) 配置 DRM 模 块 


配置 DRM 的 前 两 步 与 图 6-23 和 6-24 完 全 相同 ， 在 图 6-24 所 示 的 界面 选 
择 "Graphics support" 后 ， 将 出 现 如 图 6-27 所 示 的 界面 。 


[8] Enable modesetting on intel by default 


图 6-27 配置 内 核 文 持 DRM 


在 图 6-27 中 ， 首 先 选 中 "Direct Rendering Manager"， 表 示 需 要 内 核 支 持 
DRM， 这 是 DRM 的 通用 部 分 。 然 后 还 要 选中 驱动 具体 GPU 的 模块 ， 比 如 适 
合 笔者 测试 机 器 的 DRM 模 块 为 "Intel 8xx/9xx/G3x/G4x/HD Graphics"， 并 且 


要 人 勺 选 其 下 的 子 选 项 "Enable modesetting on intel by default"， 这 个 特性 驶 是 


所 谓 的 KMS (Kernel Mode Setting) 。 对 于 Intel 的 GPU， 这 是 必须 要 选择 
的 ， 否 则 用 户 空 间 的 2D 和 3D 张 动 可 能 都 会 遇 到 麻烦 。 


一 切 配置 好 后 ， 那 么 如 何 确定 我 们 的 配置 是 正确 的 ， 并 且 已 经 生效 
呢 ? 我 们 可 以 按 如 下 方法 验证 。 


验证 2D 驱 动 


可 以 通过 查看 X 的 日 志文 件 确 认 GPU 的 2D 驱 动 是 否 已 经 被 正确 加 载 。 
比如 在 笔者 使 用 的 男 外 一 台 真 实测 试 机 上 ，Intel 的 2D 驱 动 成 功 加 载 后 输出 
的 初始 化 信息 如 下 : 


root@vita:~# cat /var/log/Xorg.0.1og 


48.560] (II) intel: Driver for Intel Integrated Graphics 
Chipsets: i810, 


49.277] (==) intel(0): Depth 24, (--) framebuffer bpp 32 

49.287] (==) intel(0): RGB weight 888 

49.287] (==) intel(0): Default visual is TrueColor 

49.287] (II) intel(0): Integrated Graphics Chipset: Intel(R) 945GME 
49.288] (--) intel(0): Chipset: "945GME" 


[ 49.335] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 
600 601 603 625 +hsync +vsync (35.2 kHz 4d) 
[ 49.381] (II) intel(0): EDID for output VGAl 
[ 49.381] (II) intel(0): Output LVDS1 connected 
| 49.381] (II) intel(0) : Output VGA1 disconnected 


验证 3D 驱 动 


可 以 使 用 Mesa 提 供 的 工具 ， 如 glxinfo， 查 看 GPU 的 3D 驱 动 是 否 已 经 正 
确 加 载 。 读 者 可 以 从 Mesa 的 网 站 下 载 并 编译 工具 glxinfo， 或 者 偷 个 懒 ， 从 
答 主 系统 复制 过 来 一 个 ， 只 要 版 本 差别 不 十 特 别 大 ， 一 般 都 可 以 正常 运 
行 。 可 以 远程 登录 ， 或 者 在 测试 机 器 的 本 地 运行 一 个 终端 ， 使 用 glxinfo 命 
令 查 看 3D 驱 动 是 否 已 经 正常 工作 : 


root@vita:~# export DISPLAY=:0.0 
root@vita:~# ./glxinfo 


OpenGL renderer string: Mesa DRI Intel(R) 945GME x86/MMX/SSE2 


再 比如 在 笔者 的 答 主 机 上 使 用 命令 glxinfo 查 看 ， 显 示 如 下 : 


root@baisheng:~# glxinfo | grep "renderer string" 
OpenGL renderer string: Mesa DRI Intel (R) Sandybridge Mobile 
x86/MMX/SSE2 


仔细 观察 glxinfo 的 输出 ， 可 以 看 到 在 3D 泻 染 时 ， 使 用 的 是 Intel GPU 的 
3D 了 驱动。 如 果 是 软件 泻 染 ， 则 输出 类 似 如 下 : 


OpenGL renderer string: Software Rasterizer 


6.9 安装 图 形 库 


前 面 ， 我 们 使 用 Xib 编 写 了 一 个 小 程序 。 但 是 我 们 也 看 到 ，Xlib 征 多 人 么 
的 原始 ， 使 用 X 提 供 的 库 编 写 一 个 如 此 简单 的 程序 是 多 么 的 复杂 ， 更 别提 具 
有 复杂 图 形 用 户 界面 的 程序 了 。 所 以 和 多 辈 开发 者 们 前 赴 后 继 ， 演 试 在 XIib 的 
基础 上 为 X 开 发 更 高 级 的 图 形 库 ， 这 些 图 形 库 通 常 修 称 为 Widget Libraries 或 
Toolkits， 其 中 最 著名 的 就 是 GTK 和 QT。 这 些 图 形 库 引入 了 控件 的 概念 ， 极 
大 简化 了 程序 开发 ， 也 提高 了 开发 效率 。 


我 们 选择 GTK 作 为 vita 系 统 的 图 形 库 。 这 一 方 ， 我 们 束 来 编译 安 效 
GIK。 相 比 于 安装 X， 几 形 库 的 安装 过 程 相对 要 人 简单， 但 是 我 们 也 提供 了 一 
个 编译 脚本 build-gtk.sh。 必 要 时 ， 读 者 可 以 参考 这 个 脚本 。 


6.9.1 ”安装 GLib 和 libffi 


GLib 是 GTK+ 和 GNOME 工 程 的 基础 底层 核心 程序 库 ， 是 一 个 实用 的 轻 
量 级 的 库 ， 它 提供 常用 的 数据 结构 、 相 关 的 处 理 函 数 和 一 些 运行 时 支承 机 
制 ， 如 事件 循环 、 线 程 、 对 象 系统 等 。 因 此 安装 GTK+ 前 首先 需要 安装 
GLib。GLib 目 前 也 由 开发 GTK+ 的 团队 维护 。 


因为 GLib 提 供 的 对 象 系统 (GObject) 可 以 绑 定 到 多 种 语言 ， 常 见 的 如 
C、Python、Ruby 等 ， 因 此 ，GLib 的 对 象 系统 借助 库 libffi 处 理 不 同 语言 间 的 


函数 调用 。1lib 任 是 专门 设计 的 一 个 库 ， 主 要 用 于 不 同 语言 间 的 相互 调用 。 
因此 ， 安 装 GLib 前 还 需要 安装 libffi 。 


libffi 和 GLib 的 编译 安装 命令 如 下 : 


vita@baisheng:/vita/builds tar xvf ../source/libffi-3.0.11.tar.gz 

vita@baisheng:/vita/build/libffi-3.0.11$ ./configure \ 
--prefix=/usr 

vita@baisheng:/vita/build/libffi-3.0.11$ make install 

vita@baisheng:/vita/build/libffi-3.0.11$ find $SYSROOT -name \ 
"*.la" -exec rm -f '{}' \; 


vita@baisheng:/vita/builds$ tar xvf ../source/glib-2.32.4.tar.xz 

vita@baisheng:/vita/build/glib-2.32.4$ ./configure --prefix=/usr 

vita@baisheng:/vita/build/glib-2.32.4$ make install 

vita@baisheng:/vita/build/glib-2.32.4$ find $SYSROOT -name \ 
"*.la" -exec rm -f '{}' \; 


6.9.2 ”安装 ATK 


ATK (Accessibility ToolKit) 是 GTK 中 实现 辅助 功能 使 用 的 库 ， 包 括 辅 
助 视觉 、 听 觉 、 打 字 等 。 这 个 库 也 是 别 无 选择 ， 必 须要 安装 的 ， 安 装 命令 


如 下 : 


vita@baisheng:/vita/builds$ tar xvf ../source/atk-2.4.0.tar.xz 

vita@baisheng:/vita/build/atk-2.4.0$ ./configure --prefix=/usr 

vita@baisheng:/vita/build/atk-2.4.0$ make install 

vita@baisheng:/vita/build/atk-2.4.0$ find $SYSROOT -name \ 
wlan" =exec rm =£ "{}' \; 


6.9.3” 安 疙 libpng 


图 形 库 当然 离 不 开 图 片 格式 处 理 的 库 ， 常 用 的 图 片 格式 有 多 种 ， 比 如 
PNG、JPEG 等 。 但 是 为 了 简单 起 见 ，vita 系 统 只 支持 PNG 图 片 格式 。 处 理 
PNG 图 形 格 式 的 库 是 libpng， 安 装 命令 如 下 : 


vita@baisheng:/vita/builds$ tar xvf ../source/libpng-1.5.12.tar.xz 

vita@baisheng:/vita/build/libpng-1.5.12$ ./configure \ 
--prefix=/usr 

vita@baisheng:/vita/build/libpng-1.5.12$ make install 

vita@baisheng:/vita/build/libpng-1.5.12$ find $SYSROOT -name \ 
"*.la'" -exec rm -f '{}' \; 


6.9.4 ”安装 GdkPixbuf 


GTK 使 用 GdkPixbuf 进 行 图 片 的 泻 染 ， 是 GTK 图 形 库 的 基本 依赖 之 一 ， 
是 必须 安装 的 ， 安 装 命令 如 下 : 


vita@baisheng:/vita/builds$ tar xvf \ 
../source/gdk-pixbuf-2.26.3.tar.xz 
vita@baisheng:/vita/build/gdk-pixbuf-2.26.3$ patch -pl \ 
< ../../source/gdk-pixbuf-2.26.3-disable-test.patch 
vita@baisheng:/vita/build/gdk-pixbuf-2.26.3$ ./configure \ 
--prefix=/usr --without-libtiff --without-libjpeg 
vita@baisheng:/vita/build/gdk-pixbuf-2.26.3$ make install 
Vita@baisheng:/vita/build/gdk-pixbuf-2.26.3$ find $SYSROOT \ 
-name "*.l]a'" -exec rm -f '{}' \; 


为 简单 起 见 ， 我 们 禁 掉 了 其 对 JPEG 和 TIFF 格 式 的 支持 ， 否 则 ， 还 需要 
安装 如 库 libpng 一 样 操作 JPEG 和 TIFF 格 式 的 库 。 所 以 ， 读 者 在 vita 上 使 用 
GTK 开 发 程序 时 ， 也 不 要 使 用 JPEG 和 TIFF 格 式 的 图 片 。 当 然 除了 PNG 格 
式 ，GdkPixbuf 也 默认 文 持 其 他 一 些 格式 ， 在 安装 后 ， 读 者 可 以 使 用 如 下 命 
令 查 看 其 支持 的 图 片 格式 : 

vita@baisheng:/vitas 1s \ 
/vita/sysroot/usr/1ib/gdk-pixbuf-2.0/2.10.0/loaders/ 

libpixbufloader-ani.so libpixbufloader-icns.so 

libpixbufloader-png.so 1libpixbufloader-ras.so 


libpixbufloader-xbm.so libpixbufloader-bmp.so 


libpixbufloader-wbmp.so 


6.9.5 ”安装 Fontconfig 


Linux 最 初 在 我 国 的 程序 员 中 流行 时 ， 有 很 多 程序 员 热 衷 于 Linux 的 美 
化 ， 其 中 优化 文字 的 显示 征 其 中 主要 内 容 之 一 ， 至 今 在 各 个 Linux 论 坛 仍 然 
可 见 Linux 美 化 的 身影 。 文 本 泻 染 比较 和 烦琐， 除了 反 术 原因 外 ， 文 本 处 理 机 
制 不 断 的 发 展 变化 ， 从 最 初 的 X 的 核心 字体 ， 到 X 的 字体 服务 器 ， 再 到 现在 
广泛 采用 的 客户 问 泻 染 ， 也 给 这 个 本 喘 束 不 是 特别 容易 理解 的 领域 增加 了 


民 多 复 红 全 


— 


几 是 涉及 字体 相关 的 地 方 ， 我 们 经 常 看 到 如 Fontconfig 、Freetype 、 
Pango， 甚 至 更 多 ， 这 些 库 在 文本 洽 染 中 都 担任 什么 角色 ? 它们 之 间 的 关系 
又 是 什么 ? 在 我 们 埋头 搭建 系统 时 ， 还 是 要 不 时 抬头 看 看 路 的 。 下 面 ， 我 
们 就 结合 图 6-28 来 简单 地 介绍 一 下 文本 的 泻 染 。 


| cmap 1 glyf 
| character |glyph 
| code id 
| L 
| 4C 5 对 . 
: a 你 你 好 Linux! 
更 | 个 
Text: 你 好 Linux! :| |4F60 el 
Code: 4F60 597D 4C 69 ..， | …， rm 
Application | cmap 2 
Screen 
Font A 
Font B | 
Fonts 


图 6-28 文本 洽 染 过 程 示 意图 


(1) 字符 编码 (character code) 


虽然 我 们 在 写 程序 时 ， 直 接 使 用 可 读 的 字符 ， 但 事实 上 ， 在 程序 内 
部 ， 是 用 字符 的 编码 来 代表 字符 的 。 字 符 的 编码 有 多 种 标准 ， 比 如 ISO- 
8859 系 列 编码 ，Unicode 编 码 以 及 我 国 的 GB18030 等 。 


假设 系统 使 用 UTF8 编 码 ， 当 程序 准备 显示 字符 串 “ 你 好 Linux!” 时 ， 程 
序 中 将 以 编码 "4F60 597D 4C 69..." 来 记录 这 个 字符 串 。 


(2) 字形 (glyph) 


字形 是 字 的 形体 的 简称 ，GB/T 16964《 信 息 技术 字 型 信息 交换 》 中 关 
于 字形 的 的 定义 为 : 一 个 可 以 辨认 的 抽象 的 图 形 符 号 ， 它 不 依赖 于 任何 特 


定 的 设计 。 


这 样 解 释 读者 可 能 依然 会 感到 比较 生 葛 ， 因 为 平时 我 们 很 少 使 用 这 个 
概念 ， 但 是 提 到 字体 ， 大 家 束 一 定 比 较 熟 悉 了， 因为 操作 系统 中 一 定 要 安 
装 字 体 文件 的 ， 否 则 是 不 能 正确 显示 字符 的 。 而 所 谓 的 这 个 字体 文件 ， 其 


实 束 是 字形 的 集合 。 


以 TrueType 字 体 文件 为 例 ， 其 中 包含 两 个 关键 的 数据 结构 : 


令 一 个 十 字形 表 ， 也 称 为 glyf。 字 形 表 中 每 一 项 代表 一 个 字形 ， 使 用 子 
形 索 引 访 问 其 中 的 字形 。TrueType 的 字形 表 中 ， 每 个 字形 的 描述 并 非 如 图 6- 
28 中 的 字形 表 (glyf) 中 显示 的 那样 直观 ， 字 形 表 中 描述 的 字形 信息 都 是 矢 
量 的 ， 字 符 的 每 一 个 笔画 都 是 由 多 条 曲线 包围 而 形成 的 。 一 次 曲线 需要 两 


个 点 来 确定 ， 二 次 需要 三 个 点 ， 三 次 就 需要 四 个 点 。 字 体内 部 保存 了 这 些 
点 的 坐标 。 


4 一 个 是 字符 编码 到 字形 映射 表 (Character to Glyph Mapping) ， 简 称 
cmap。 读者 可 能 会 有 个 疑问 ，cmap 中 的 第 二 列 为 什么 不 是 字形 ， 而 是 字形 
索引 呢 ? 原因 是 字体 文件 可 能 使 用 在 不 同 的 编码 环境 中 ， 所 以 字体 文件 可 
能 包含 多 个 cmap 表 ， 比 如 UTF8 对 应 一 个 cmap 表 ，GB18030 对 应 另外 一 个 
cmap 表 。 另 外 ， 一 个 字体 文件 中 也 可 能 不 只 包含 一 种 字体 。 


(3) 排版 〈layout) 


每 每 谈 到 文本 泻 染 时 ， 大 家 更 多 的 关注 在 字体 上 ， 却 往往 忽略 了 文本 
的 布局 排版 。 实 际 上 ， 文 字 的 排版 是 重要 而 且 复杂 的 。 排 版 引擎 需要 将 单 
个 字符 按照 一 定 的 间距 美观 的 排列 起 来 。 


除了 处 理 字形 信息 外 ， 由 于 世界 上 有 多 种 文字 体系 ， 因 此 ， 文 本 可 能 
征 多 种 语言 混合 的 。 而 且 ， 还 有 像 阿 拉 伯 文 、 硕 伯 来 文 这 种 文字 体系 是 从 
右 向 左 书 写 ， 更 别提 布局 规则 极其 复杂 的 印度 系 文字 。 


可 见 ， 排 版 引擎 是 一 位 真正 的 幕后 英雄 。 而 且 ， 文 本 泻 染 的 过 程 都 十 
由 排版 引擎 率 尖 开始 的 ， 不 同 的 图 形 库 可 能 使 用 不 同 的 排版 引擎 ，GTK 使 
用 的 排版 引擎 是 Pango 。 


在 将 字符 编码 转化 为 字符 前 ， 首 先 需 要 确定 字体 文件 ， 否 则 巧 妇 也 难 
为 无 米 之 次 。 一 个 系统 中 可 能 安装 了 多 个 字体 文件 ， 因 此 ， 在 众多 的 字体 
文件 中 要 选择 一 个 最 合适 的 ， 这 束 是 Fontconfig 的 主要 任务 之 一 。 


进行 文本 洽 染 时 ，Pango 收 集 来 目 各 方 的 字体 信息 ， 如 系统 主题 中 设置 
如 下 : 
We 
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程序 自身 的 设置 如 下 : 


pango font description from string!( "Serif bold 12" ); 


可 能 还 有 来 自如 图 形 库 等 其 他 方面 的 信息 ， 总 之 ，Pango 最 后 加 工 出 一 
个 字体 描述 ， 将 它 传递 给 Fontconfig， 这 个 描述 称 为 模式 (Pattern) ， 
Fontconfig 根 据 配置 文件 对 这 个 模式 进行 进一步 加 工 ，Fontconfig 通 肖 会 修改 
或 者 增加 一 些 属 性 。 


最 终 ，Fontconfig 以 加 工 好 的 模式 在 众多 的 字体 中 匹配 一 个 最 合适 的 字 
体 。 


(5) 光栅 化 


一 旦 字体 确定 后 ，Fontconfig 使 用 库 Freetype 提 供 的 接口 ， 确 定 字 符 编 
码 对 应 的 字形 索引 ， 依 据 的 就 是 如 TrueType 字 体 文件 中 的 cmap 表 。 最 后 
Wn A WA 引 ， 从 字体 文件 的 字形 表 中 获取 摘 述 字形 的 矢量 信息 
构建 具体 的 字形 ， 这 个 过 程 也 叫 光 栅 化 。 经 过 光栅 化 的 字符 编码 ， 束 是 一 
普通 图 形 了 ， 接 下 来 无 论 是 显示 到 具体 窗口 中 ， 还 是 进行 其 他 处 理 ， 部 与 
处 理 普 通 的 图 形 完全 相同。 


理解 了 各 个 库 的 作用 后 ， 下 面 我 们 开始 安装 这 些 库 。 


Freetype 在 前 面 安 装 X 时 已 经 安装 ， 接 下 来 只 需 安装 Fontconfig 和 
Pango ° ne 而 Pango 又 基于 Cairo 进 行 字体 泻 染 ， 所 
以 ， 这 里 的 安装 顺序 看 上 去 有 点 奇怪 。 我 们 先 安装 Fontconfig， 中 间 插 播 
Cairo， 然 后 才 安 装 Pango。 


安装 Fontconfig 的 命令 如 下 ; 


vita@baisheng:/vita/builds tar xvf \ 
../source/fontconfig-2.10.1.tar.bz2 

vita@baisheng:/vita/build/fontconfig-2.10.1$ ./configure \ 
--prefix=/usr --sysconfdir=/etc --localstatedir=/var \ 
--disable-docs --without-add-fonts 

vita@baisheng:/vita/build/fontconfig-2.10.1$ make install 

vita@baisheng:/vita/build/fontconfig-2.10.1$ find $SYSROOT \\ 
-name "*.la'" -exec rm -f '{}' \; 


6.9.6 ”安装 Cairo 


Cairo 征 一 个 天 量 图 形 库 ，GTK 使 用 其 作为 绘制 后 端 。 换 句 话 说，GTK 
的 绘制 动作 由 Cairo 完 成 。 看 到 这 里 ， 读 者 可 能 会 非常 困惑 : X 上 的 应 用 不 
是 由 X 服 务 器 负责 绘制 吗 ? 没 错 ， 和 暂且 不 提 我 们 第 8 章 讨论 的 DRI。 事 实 
上 ， 即 使 普通 的 2D 应 用 也 是 可 以 自己 绘制 的 ， 只 不 过 ， 应 用 是 将 内 容 绘制 
在 一 个 离 屏 的 区 域 ， 但 是 最 后 还 是 要 请 求 X 服 务 器 将 绘制 的 内 容 显示 到 屏幕 
上 。 应 用 或 者 将 绘制 的 内 容 复制 到 X 服 务 右 ， 或 者 使 用 X 提 供 的 RENDER 打 
展 。 当 然 ， 应 用 也 可 以 将 全 部 绘制 请 求 X 服 务 器 完成 ， 这 束 要 看 具体 图 形 库 
采用 的 策略 了 。 


安装 Cairo 的 命令 如 下 : 


vita@baisheng:/vita/builds$ tar xvf ../source/cairo-1.12.2.tar.xz 

vita@baisheng:/vita/build/cairo-1.12.2$ ./configure \ 
--prefix=/usr 

vita@baisheng:/vita/build/cairo-1.12.2$ make install 

vita@baisheng:/vita/build/cairo-1.12.2$ find $SYSROOT -name \ 
"*.la" -exec rm -f '{}' \; 


6.9.7 ”安装 Pango 


安装 Pango 的 命令 如 下 : 


vita@baisheng:/vita/builds tar xvf ../source/pango-1.30.1.tar.xz 

vita@baisheng:/vita/build/pango-1.30.1$ ./configure \ 
--prefix=/usr --sysconfdir=/etc 

vita@baisheng:/vita/build/pango-1.30.1$ make install 

vita@baisheng:/vita/build/pango-1.30.1$ find $SYSROOT -name \ 
"*.la" -exec rm -f '{}' \; 


6.9.8 ”安装 libXi 


图 形 库 当然 是 要 接收 用 户 输入 的 ，X 输 入 扩展 协议 的 实现 是 库 ]ibXi, 


装 命令 如 下 : 


闪 


vita@baisheng:/vita/builds tar xvf \ 

5 BOULESE/XT7S 7 /11iDXLi=16% 1 .tarlBdz2 
vita@baisheng:/vita/build/libXi-1.6.1$ ./configure --prefix=/usr 
vita@baisheng:/vita/build/libXi-1.6.1$ make install 
vita@baisheng:/vita/build/libXi-1.6.1$ find $SYSROOT -name \ 

"*.la'" -exec rm -f '{}' \; 


6.9.9 安 痛 GTK 


GTK 的 基本 依赖 已 经 安装 完成 ， 只 差 完 成 最 后 一 步 了 ， 安 装 GTK 的 命 
令 如 下 : 


vita@baisheng:/vita/builds$ tar xvf ../source/gtk+-3.4.4.tar.xz 

vita@baisheng:/vita/build/gtk+-3.4.4$ ./configure \ 
--prefix=/usr --sysconfdir=/etc 

vita@baisheng:/vita/build/gtk+-3.4.4$ make install 

vita@baisheng:/vita/build/gtk+-3.4.4$ find $SYSROOT -name \ 
"*.la" -exec rm -f '{}' \; 


至 此 ， 图 形 库 GTK 的 安装 过 程 已 经 全 部 完成 ， 读 者 可 以 将 /vita/sysroot 
目录 下 的 文件 系统 更 新 到 vita 的 根 文 件 系 统 


6.9.10 ”安装 GTK 岁 形 库 的 善后 工作 


更 新 了 vita 系 统 的 根 文件 系统 后 ， 在 运行 使 用 GTK 编 写 的 程序 前 ， 我 们 
还 要 在 vita 系 统 上 为 图 形 库 做 一 点 收尾 工作 。 注 意 下 面 两 个 操作 需要 在 使 用 
安装 了 GTK 疼 形 库 的 根 文件 系统 重 局 vita 系 统 后 进行 。 


(1) 为 Pango 创 建 语系 和 模块 对 应 关系 的 文件 


不 同 语系 ， 对 布局 有 不 同 的 要 求 ， 全 世界 有 各 种 各 样 的 语系 ， 如 汉 
语 、 阿 拉 伯 语 、 印 度 语 等 。Pango 采 用 模块 化 的 方式 提供 对 这 些 语 系 的 文 
持 。 为 了 提高 效率 ， 在 运行 时 ，Pango 不 会 到 文件 系统 中 解析 具体 的 模块 ， 
查看 其 支持 的 语系 ， 而 是 直接 读 取 /etc/pango 目 隶 下 的 文件 pango.modules， 
其 中 记录 了 每 个 模块 及 其 支持 的 语系 。 因 此 ， 我 们 需要 为 Pango 创 建文 件 


pango.modules， 命 令 如 下 : 


root@vita:~# pango-querymodules > /etc/pango/pango.modules 


下 面 是 创建 的 文件 pango.modules 中 的 片段 : 


root@vita:~# cat /etc/pango/pango.modules 


/usr/lib/pango/1.6.0/modules/pango-syriac-fc.so \ 
SyriacSscriptEngineFc PangoEngineShape PangoRenderFc syriac:* 


/usr/lib/pango/1.6.0/modules/pango-basic-fc.so \ 
BasicScriptEngineFc PangoEngineShape PangoRenderFc latin:* \ 
Cyrillic:* greek:* armenian:* georgian:* runic:* ogham:* \ 
bopomofo:* cherokee:* coptic:* deseret:* ethiopic:* gothic:* \ 
han:* hiragana:* katakana:* old-italic:* canadian-aboriginal:*\ 
yi:* braille:* cypriot:* limbu:* osmanya:* shavian:* linear-b:*\ 


ugaritic:* glagolitic:* cuneiform:* phoenician:* common: 


可 见 ， 模 块 pango-syriac-fc.so 负 责 处 理 叙 利 亚 语 (syriac) ， 模 块 pango- 
basic-fc.so 负 责 处 理 拉 丁 语 (latin) 、 和 希腊 语 (greek) ， 包 括 我 们 的 汉语 
(han) 


(2) 为 库 GdkPixbuf 创 建 模块 信息 文件 


在 安装 库 GdkPixbuf 时 ， 我 们 看 到 ，GdkPixbuf 使 用 模块 的 形式 支持 各 图 
形 格式 。 因 此 ， 在 这 个 库 初始 化 时 ， 需 要 加 载 这 些 模 块 。 但 是 这 些 模块 存 
储 在 文件 系统 的 什么 位 置 ， 每 个 模块 又 支持 什么 图 形 格式 等 ， 诸 如 此 类 信 
息 从 哪里 获取 呢 ? 为 了 提高 加 载 速 度 ，GdkPixbuf 没 有 去 再 次 扫描 每 个 模 
块 ， 而 是 直接 从 系统 的 一 个 文件 中 读 取 ， 因 此 ， 我 们 需要 为 GdkPixbuf 创 建 
这 个 文件 ， 命 令 如 下 : 


root@vita:~# gdk-pixbuf-query-loaders --update-cache 


gdk-pixbuf-query-loaders 将 到 模块 所 在 的 目录 去 扫 摘 各 个 模块 ， 然 后 将 
模块 信息 记录 下 来 ， 默认 情况 下 ， 记 杂 在 下 面 这 个 文件 中 : 


/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache 


当然 如 果 将 模块 信息 写 到 其 他 文件 了 ， 需 要 通过 环境 变量 
GDK_PIXBUF_MODULE_FILE 指 定 出 来 。 


以 vita 系 统 为 例 ， 该 文件 中 记录 的 信息 大 致 如 下 : 


root@vita:~# cat /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache 


"/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so'" 
"png" 5 "gdk-pixbuf" "The PNG image format" "LGPL" 

"image/png" "" 

1 png nh 1 

"\211PNG\r\n\032\n" "" 100 


6.9.11 “一 个 简单 的 GTK 程 序 


最 后 ， 我 们 使 用 一 个 简单 的 程序 来 测试 我 们 的 GTK 是 否 工作 正常 ， 程 
序 代 码 如 下 : 


hello gtk/hello gtk.c: 
#include <gtk/gtk.h> 
int main(int argc, char *argv[] ) 
{ 
GtkWidget *window; 
GtkWidget *]lb]l; 
gtk init(&argc, &argv); 
window = gtk window new(GTK WINDOW TOPLEVEL); 


gtk window set default size(GTK WINDOW (window), 300, 200); 


lbl = gtk label new("Hello GTK!"); 

gtk container add (GTK CONTAINER (window), 1b1); 
gtk widget show all (window); 

gtk main(); 


return 0; 


编译 该 程序 的 Makefile 文 件 如 下 : 


hello gtk/Makefile: 


CFLAGS= “ pkg-config --cflags gtk+-3.0 -~ 
LDFLAGS= “pkg-config --cflags gtk+-3.0° 


hello gtk: hello gtk.o 


install: 
install -m 755 hello gtk $ (DESTDIR) /usr/bin/ 


clean: 
rn “=rf£, hello. gtk wo 


可 见 ， 同 样 是 显示 一 个 简单 的 窗口 ， 使 用 GTK 编 写 就 简单 多 了 ， 那 些 
烦琐 的 细 蔬 已 经 实现 在 如 GTK 等 这 些 图 形 库 中 。 编 译 这 个 程序 ， 并 将 其 复 
制 到 vita 系 统 并 运行 ， 步 又 与 程序 hello_x 完 全 相同 。 


如 采 GTK 安 狠 正 第 ， 在 vita 系 统 上 我 们 将 看 到 类 似 图 6-29 所 示 的 输出 。 
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图 6-29 一 个 简单 的 GTK 程 序 


但 是 ， 我 们 发 现 麻 烦 来 了 : 文本 并 没有 显示 出 来 ， 而 是 显示 了 一 串 “ 方 
框 *”。 如 果 对 字体 渲染 有 一 些 经 验 束 会 知道 ， 这 里 所 谓 的 “ 方 框 ” 是 在 找 不 到 
字体 时 使 用 的 默认 的 一 个 特殊 字符 。 


观察 终端 上 Pango 输 出 : 


root@vita:~# hello gtk & 


(hello gtk:249): Pango-WARNING **: failed to choose a font, expect ugly output. 
engine-type='PangoRenderFc', script='latin' 


Pango 的 输出 也 印证 了 我 们 的 推论 ，Pango 明 确 提 示 ， 找 不 到 匹配 的 字 
体 。 


读者 可 能 会 再 次 陷入 了 困惑 中 ， 在 测试 hello_x 时 ， 为 什么 hello_x 束 可 
以 找到 字体 呢 ? 下 一 节 ， 我 们 就 来 讨论 这 个 问题 ， 并 为 vita 系 统 安装 字体 。 


6.10 ”安装 字体 


对 于 基于 Xlib 编 写 的 程序 ， 一 般 徐 单 的 字符 使 用 X 中 的 内 置 字体 就 可 以 
应 付 了 。X 的 内 置 字体 在 libXfont 中 : 


libxXfont-1.4.5/src/built-ins/fonts.c: 


static const char file 6x13[] = { 
NBT "Noo TN" NL" "2" 
GDODL ENODST DTNO6D5 LITOLs Udella TMS NS TNLTI: 
NOoGZls L744 JNISSY; TIA NO TAN2000 .DNS NOOOL: 
"NOO0O®, 


}; 

其 中 file_6x13 中 记录 的 束 古 简单 的 点 阵 字 体 ， 又 称 位 图 字体 ， 显 然 这 个 
内 置 的 点 阵 字 体 是 把 每 一 个 字符 都 分 成 6x23 个 点 ， 然 后 用 每 个 点 的 虚实 来 
表示 字符 的 轮廓 。 


守 的 原因 。 但 是 既然 有 内 置 的 字体 ， 那 为 什么 使 用 GTK 的 程序 不 能 
守 昵 ?原因 是 GTK 程 序 的 字体 是 在 客户 剖 绘 制 的 ， 客 户 端 绘制 完成 
后 ， 将 字形 位 图 传 给 X 服 务 器 。 而 GTK 中 并 没有 像 libXfont 那 样 内 置 了 字 
体 ， 所 以 如 果 系统 中 没有 安 洲 字体 ， 当 然 应 用 束 找 不 到 字体 了 。 因 此 ， 我 
们 需要 安装 字体 。 


字体 的 安装 非常 简单 ， 直 接 把 字体 文件 复制 到 相关 的 目录 下 即 可 。 但 
是 安装 在 哪个 目录 下 呢 ? 前 面 我 们 已 经 看 到 ，Linux 使 用 Fontconfig 寻 找 字 


体 ， 因 此 这 个 问题 要 问 Fontconfig。 没 错 ，Fontconfig 在 其 配置 文件 中 明确 指 
明了 其 寻找 字体 文件 的 目录 : 


/vita/sysroot/etc/fonts/fonts.conf: 
<!-- Font directory list --> 
<dir>/usr/share/fonts</dir> 


<dir Breflxsrxdg"Sftontsz/dlrs 


<!-- the following element will be removed in the future --> 
<dir>~/.fonts</dir> 


这 里 ， 我 们 使 用 文 泉 驿 字 体 ， 并 将 其 安装 到 vita 系 统 的 /usrshare/fonts 目 
录 下 ， 命 令 如 下 : 


root@vita:~# mkdir -p /usr/share/fonts/ 
root@baisheng:~# scp \ 


/usr/share/fonts/truetype/wqy/wqy-microhei.ttc \ 
192.,.168.56.2;/usr/share/fonts/ 


安装 完 字体 后 ， 再 次 执行 gtk_hello， 就 会 发 现 字符 不 再 是 一 个 一 个 
的 “ 方 杠 "了 ， 如 图 6-30 所 示 。 


11.10 [正在 运行 ] - Qracle VM VirtualB 


Hello GTK! 


总 信 俏 归 E 使 回 右 ctrl 
图 6-30 安装 字体 后 的 GTK 程 序 


而 且 ， 可 以 在 vita 系 统 的 /var/cache/fontconfig 目 录 下 看 到 类 似 如 下 的 
Fontconfig 用 于 快速 搜索 字体 的 缓存 文件 : 


root@vita:~# ls /var/cache/fontconfig/ 

3830d5c3ddfd5cd38a049b759396e72e-le32d4 .cache-3 
99e8ed0e538f840c565b6ed5dad60d56-le32d4 .cache-3 
7Tef2298fde4lcc6eeb7af42e48b7d293-le32d4 .cache-3 


至 此 ， 基 础 的 图 形 环境 已 经 安装 完毕 ， 可 以 运行 基本 的 具有 图 形 界面 
的 程序 了 。 但 是 我 们 也 看 到 ， 这 个 图 形 环境 是 个 裸 环境 ， 没 有 任务 条 、 没 


有 吕 面 背景 。 应 用 程序 的 窗口 也 是 个 禄 窗口 ， 没 有 标题 栏 、 没 有 边框 ， 不 
能 最 大 化 和 最 小 化 、 不 能 关闭 ， 也 不 能 移动 ， 甚 至 当局 动 多 个 应 用 时 ， 我 
们 也 没有 办 法 在 多 个 应 用 间 切 换 等 。 这 些 问 题 ， 我 们 留 给 下 一 章 。 


第 7 草 ”构建 呆 面 环境 


计算 机 领域 中 的 桌面 环境 (Desktop Environment) 其 实 是 一 种 比喻 的 说 
法 ， 即 图 形 用 户 界面 就 像 物理 书桌 一 样 ， 其 上 可 以 放置 文件 夹 、 文 档 等 。 
桌面 最 初 用 来 特 指 个 人 计算 机 (PC) ， 但 是 现在 不 只 个 人 计算 机 有 图 形 界 
面 环境 ， 服 务 器 、 媒 入 式 设备 等 基本 都 提供 桌面 环境 。 桌 面 环境 包括 窗口 
管理 器 、 任 务 条 等 基本 组 件 ， 除 了 这 些 基 本 的 组 件 外 ， 有 的 桌面 环境 还 提 
供 文件 管理 器 、 控 制 面板 等 。 


桌面 环境 是 操作 系统 中 人 机 交互 的 关键 部 分 ， 理 解 它 的 基本 运作 原 
理 ， 无 论 是 对 理解 操作 系统 ， 还 是 对 开发 应 用 程序 ， 都 有 极 大 的 帮助 。 我 
们 处 于 这 样 一 个 追求 个 性 的 年 代 ， 无 论 是 用 于 消费 类 电子 设备 的 移动 系 
统 ， 还 是 用 于 PC 的 中 规 中 和 矩 的 桌面 系统 ， 人 们 都 已 不 再 满足 于 于 篇 一 律 的 
桌面 。 打 造 一 个 全 新 的 个 性 化 桌面 ， 绝 不 只 是 停留 在 更 改 个 背景 图 、 换 个 
主题 这 个 层面 ， 我 们 需要 更 大 的 音 新 。 但 是 如 采 对 蝎 面 环境 的 基本 原理 都 
不 其 了 解 ， 那 义 何 谈 去 开发 打造 具有 创造 性 的 用 户 交 互 。 


因此 ， 在 本 革 中 我 们 璐 领 读者 从 头 构建 一 个 基本 的 桌面 环境 ， 包 括 窗 
口 管理 右 、 任 务 条 以 及 一 个 显示 加 面 背 景 的 组 件 。 为 了 使 读者 更 能 深刻 体 
会 X 的 客户 /服务 右 模 型 ， 窗 口 管 理 絮 基于 Xlib 编 写 ， 而 任务 条 等 组 件 则 展示 
了 使 用 GTK 图 形 库 的 编程 方法 。 


限于 篇 幅 ， 我 们 没有 将 全 部 源 代 码 全 部 贴 到 书 中 ， 所 以 请 读者 结合 B 
书 光 盘 中 附 融 的 源 代 码 进行 阅读 。 另 外 ， 本 草 虽 然 涉及 Xlib 和 GTK 编 程 ， 但 


是 为 了 不 干扰 主线 一 构建 桌面 环境 ， 我 们 不 会 过 多 讨论 它们 的 编程 ， 其 
中 涉及 的 API， 如 有 必要 请 参考 Xlib 和 GTK 各 目的 参考 手册 。 


7.1 窗口 管理 器 


本 质 上 ， 窗 口 就 是 显示 右上 对 应 的 一 块 区域 。 对 于 一 个 运行 多 任务 的 
操作 系统 来 讲 ， 在 一 个 有 限 的 屏幕 上 可 以 同时 存在 多 个 窗口 ， 因 此 ， 用 户 
希望 多 个 窗口 之 间 可 以 协调 布局 和 平 共 至 同一 个 屏 侨 。 可 以 将 特定 窗口 切 
换 为 当前 活动 窗口 ; 可 以 按 需 改变 窗口 尺寸 ， 可 以 最 大 化 、 最 小 化 以 及 关 
闭 窗口 。 但 是 X 的 设计 哲学 是 只 提供 机 制 ， 不 提供 策略 ，X 服 务 句 只 提供 徐 
口 操作 相关 的 函数 ， 但 不 管 如 何 去 操 作 窗 口 。 于 是 诞生 了 男 外 一 个 特殊 的 X 
应 用 : 窗口 管理 器 。 


7.1.1 基本 原理 


1.X 的 窗口 


X 将 所 有 窗口 组 织 为 一 棵 树 。X 服 务 絮 启动 后 ， 将 默认 创建 一 个 窗口 ， 
这 个 窗口 充满 整个 屏幕 ， 作 为 整个 窗口 树 的 根 ， 称 为 根 窗口 (Root 
Window) ， 所 有 应 用 的 顶层 窗口 (Top-level Window) 都 是 根 窗口 的 子 窗 
国有 


假设 在 Xx 中 运行 两 个 应 用 A 和 B，A 包 含 2 个 窗口 ，B 应 包含 3 个 窗口 ， 窗 
口 之 间 的 布局 如 图 7-1 所 示 。 


Root Window 
Top Window A 


Top Window B 
Subwindow x 


Subwindow a 


Subwindow y| | spbwindow b 


图 7-1 窗口 布局 示意 图 


它们 之 间 的 树 形 关 系 如 图 7-2 所 示 。 


Root Window 


Top Window A Top Window B 


图 7-2 窗口 树 形 关系 示意 图 


窗口 管理 器 仅 管 理应 用 的 顶层 窗口 ， 即 如 图 7-2 中 的 "Top Window 
A" 和 "Top Window B"。 一 个 应 用 可 能 有 多 个 顶层 窗口 ， 除 了 应 用 的 主 窗口 


之 外 ， 对 话 框 一 般 也 是 一 个 顶层 窗口 。 而 对 于 顶层 窗口 的 子 窗口 ， 则 由 应 
用 目 己 管理 。 


在 第 6 章 中 ， 我 们 看 到 ， 无 论 是 基于 Xlib 的 程序 ， 还 是 使 用 GTK 编 写 的 
程序 ， 在 没有 窗口 管理 器 的 情况 下 ， 它 们 的 窗口 都 以 素颜" 示人， 只 是 一 
个 “ 裸 "窗口 。 一 个 典型 的 介面 应 用 的 窗口 ， 一 般 而 言 ， 包 括 一 个 标题 栏 ， 
标题 祷 上 还 可 能 显示 窗口 的 名 称 、 最 大 化 、 最 小 化 和 关闭 按钮 。 男 外 ， 窗 
口 一 般 还 有 一 个 边框 。 用 户 可 以 通过 标题 栏 移动 窗口 ， 可 以 在 边框 处 拖 动 
鼠标 改变 窗口 太 寸 ， 可 以 分 别 通过 最 大 化 、 最 小 化 和 关闭 按钮 最 大 化 、 最 
小 化 、 关 闭 窗口 。 这 些 组 件 除 了 具备 功能 外 ， 还 具备 美化 的 作用 ， 比 如 可 
以 设置 窗口 边框 的 颜色 、 阴 影 效 果 等 ， 因 此 ， 它 们 也 被 称 为 窗口 狠 饰 。 


显然 ， 窗 口 装饰 不 应 该 由 各 个 应 用 负责 ， 和 暂且 不 提 重 复 玫 动 ， 单 单一 

致 性 束 是 个 大 问题 。 如 果 任 由 应 用 目 己 绘制 ， 最 后 将 导致 窗口 标题 栏 等 逆 

饰 五 伦 八 []。 因 此 ， 在 X 中 ， 将 窗口 洲 饰 提取 为 公共 部 分 ， 由 窗口 管理 絮 统 
一 负责 。 通 常 的 实现 方式 是 ， 窗 口 管理 器 创建 一 个 窗口 ， 我 们 称 这 个 窗口 

为 Frame， 作 为 根 窗口 的 子 窗口 ， 但 古 作为 应 用 的 项 层 窗口 的 父 窗口 。 其 他 
沪 饰 ， 或 者 直接 绘制 在 Frame 窗 口上 ， 或 者 创建 新 的 泌 饰 窗口 ， 但 古 这 些 涂 
饰 窗口 也 作为 Frame 的 子 窗 口 ， 本 章 我 们 开发 的 窗口 管理 器 采用 后 者 。 应 用 
的 顶层 窗口 和 Frame 窗 口 之 间 的 关系 如 图 7-3 所 示 。 


Frame Window 


三 及 到 二 lel 


Reparent 


Top-level Window > Top-level Window 


图 7-3 顶层 窗口 和 Frame 窗 口 的 关系 


3 拦 补 事件 


X 服 务 器 维护 一 个 事件 队列 ， 在 该 队列 中 按 顺序 保存 着 发 生 的 各 个 事 
件 ， 并 周期 地 分 发 给 应 用 。 每 个 应 用 可 以 选择 对 发 生 在 某 些 窗口 上 的 哪些 
事件 感 兴趣 ， 如 果 多 个 应 用 对 同一 个 事件 感 兴趣 ，X 服 务 器 将 复制 该 事件 的 
多 个 副本 ， 并 将 其 分 发 给 各 个 对 其 感 兴趣 的 应 用 ， 如 图 7-4 所 示 。 


X client 1 X client 2 


Server Queue 
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Socket 
(Local or Network) 


图 7-4 事件 队列 


Xlib 提 供 了 函数 XSelectInput， 应 用 程序 可 以 使 用 该 范 数 选择 接收 指定 
窗口 的 事件 ， 其 函数 原型 如 下 : 


XSelectInput (Display *display, Window w, long event mask) 


其 中 参数 w 表 示 接 收发 生 在 窗口 w 上 的 事件 ，event_mask 表 示 对 哪些 事 
件 感 兴趣 ， 如 ButtonPressMask 表 示 希 望 接 收 窗口 w 的 ButtonPress 事 件 。 


一 


U 


在 这 些 事件 掩 码 中 ， 有 一 个 比较 特殊 一 SubstructureRedirectMask， 其 含 
义 是 : 当 某 个 应 用 选 定 了 某 个 窗口 的 SubstructureRedirectMask 时 ， 该 窗口 的 
子 窗口 (Substructure) 发 送 给 X 服 务 器 的 MapRequest、ConfigureRequest 和 
CirculateRequest 三 类 请 求 ， 都 将 被 重 定 癌 给 这 个 应 用 ， 这 惑 是 X 


的 "Substructure Redirection" 机 制 。 


窗口 管理 右 恰 恰 利 用 了 这 个 机 制 ， 对 根 窗口 选择 了 
SubstructureRedirectMask， 从 而 截获 了 应 用 的 顶层 窗口 的 请 求 。 其 中 最 关键 
的 十 MapRequest， 在 窗口 请 求 X 服 务 紫 显示 时 ， 其 将 向 Xx 服务 器 发 送 
MapRequest 请 求 。 在 截获 了 MapRequest 后 ， 窗 口 管理 器 创建 Frame 窗 口 ， 作 
为 根 窗口 的 子 窗口 ， 然 后 瞳 渡 陈仓 ， 将 应 用 的 顶层 窗口 从 根 窗口 脱离 ， 而 
将 其 作为 Frame 窗 口 的 子 窗 口 ， 同 时 也 创建 其 他 窗口 凌 炳 。 都 伪 猴 好 后 
口 管理 大 再 以 Frame 窗 口 的 身份 ， 请 求 X 服 务 闫 显示 Frame 窗 口 。 应 用 的 顶层 
窗口 作为 Frame 窗 口 的 子 窗 口 ， 当 Frame 窗 口 得 以 显示 后 ， 其 自然 也 被 显 
示 。 在 某 种 意义 上 ， 窗 口 管理 器 通过 Frame 窗 口 控 制 了 应 用 的 顶层 窗口 ， 从 
而 达到 管理 它们 的 目的 。 


在 应 用 的 顶层 窗口 作为 Frame 窗 口 的 子 窗口 后 ， 容 口 管理 器 还 是 要 关心 
它们 发 送 给 X 服 务 絮 与 窗口 管理 相关 的 请 求 ， 因 此 ， 如 同 设置 根 窗口 的 
SubstructureRedirectMask， 窗 口 管理 器 也 需要 设置 Frame 窗 口 的 


SubstructureRedirectMask ° 


不 知 读者 是 否 考虑 过 这 样 一 个 问题 : 既然 X 服 务 器 将 其 他 应 用 的 
MapRequest 请 求 重 定向 给 窗口 管理 器 ， 那 么 窗口 管理 器 同样 也 作为 X 服 务 器 
的 一 个 客户 程序 ， 它 也 需要 向 X 服 务 器 发 送 MapRequest 请 求 ， 比 如 请 求 显示 
Frame 等 装饰 窗口 。 如 此 这 般 ，X 服 务 名 已 不 是 将 窗口 管理 絮 发 送 给 它 的 请 
求 再 重 定向 给 窗口 管理 器 ? 如 此 往复 ， 岂 不 是 形成 了 死 循环 ? 


为 此 ， 窗 口 提供 了 一 个 属性 : override_redirect。 如 果 窗 口 的 这 个 属性 值 
为 True， 则 其 明确 告知 X 服 务 器 自己 不 需要 窗口 管理 器 的 管理 ，X 服 务 器 就 


` 会 将 这 个 窗口 的 请 求 重 定 同 给 窗口 管理 器 。 我 们 常用 的 鼠标 右键 菜单 瑟 
是 一 个 典型 的 将 属性 override_redirect 设 置 为 True 的 窗口 。 因 此 ， 窗 口 管理 大 
在 创建 Frame 等 装饰 窗口 时 ， 可 以 通过 将 它们 的 这 个 属性 设置 为 True 来 解决 
我 们 刚刚 谈 到 的 死 循环 问题 。 事 实 上 ， 即 使 不 设置 这 个 属性 ， 也 不 会 形成 
死人 循环 ，X 的 开发 者 已 经 考虑 了 这 个 问题 。 


窗口 管理 器 除了 关心 应 用 的 顶层 窗口 的 SubstructureRedirectMask 涉 及 的 
请 求 外 ， 另 外 还 要 获得 它们 的 某 些 通 知事 件 。 其 中 一 个 就 是 UnmapNotify， 
在 收 到 这 个 通知 后 ， 窗 口 管理 器 需要 清理 所 有 为 该 窗口 创建 的 对 象 ， 包 括 
窗口 装饰 等 。 所 以 除了 事件 掩 码 SubstructureRedirectMask 外 ， 窗 口 管理 器 还 
要 选择 根 窗口 和 Frame 窗 口 的 事件 掩 码 SubstructureNotifyMask 。 


4. 窗 口 间 通信 


在 一 个 标准 的 桌面 环境 下 ， 存 在 多 个 不 同 的 应 用 程序 ， 除 了 普通 的 应 
用 程序 外 ， 还 有 构成 基本 桌面 环境 的 组 件 ， 如 任务 条 等 。 而 且 ， 每 个 应 用 
的 窗口 布局 策略 不 尽 相 同 ， 比 如 普通 的 X 应 用 一 般 带 有 窗口 装饰 ， 但 是 我 们 
有 看 到 过 构成 提 面 环境 的 任务 条 妆 饰 着 标题 栏 ， 并 且 标 题 栏 上 有 最 大 化 /最 
小 化 以 及 关闭 等 按钮 吗 ? 显然 ， 这 类 组 件 不 需要 窗口 装饰 。 我 们 还 以 任务 
条 为 例 ， 在 某 些 扶 面 环境 上 ， 任 务 条 可 以 放置 在 屏 才 的 上 方 、 下 方 、 左 侧 
以 及 右 侧 。 再 比如 ， 对 话 框 的 窗口 装饰 中 通常 是 没有 最 大 化 按钮 的 。 


显然 ,窗口 管理 右 需 要 获得 窗口 的 相关 信息 ， 才 能 根据 这 些 信 息 决 定 
如 何 为 这 些 窗 口 在 同一 个 屏幕 上 协调 的 布局 以 及 如 何 装饰 这 些 
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此 ，X 提 供 了 多 种 窗口 间 通 信 的 机 制 ， 属 性 (Property) 是 窗口 管理 器 和 应 
用 的 窗口 之 间 使 用 的 主要 通信 机 制 。 


X 黑 认定 义 了 一 些 属 性 ， 这 些 属性 在 窗口 管理 器 规范 中 约定 ， 但 十 应 用 
也 可 以 自 定 义 属 性 。 在 X 中 ， 每 个 窗口 都 附着 一 个 属性 表 ， 表 中 每 一 行 大 和 致 
束 定 属性 的 名 字 和 其 对 应 的 值 。 应 用 可 以 设置 目 己 创建 的 窗口 的 属性 ， 也 
可 以 读 取 或 者 改变 其 他 应 用 的 窗口 的 属性 ， 从 而 达到 不 同窗 口 间 通 信 的 目 
的 。 


属性 保存 在 X 服 务 万 端 。 每 个 属性 都 有 一 个 名 字 ， 为 了 便于 使 用 属性 ， 
属性 的 名 字 古 可 读 性 更 好 的 ASCII 子 符 串 而 不 十 一 串 数 子 。 然 而 ， 如 果 应 用 
程序 使 用 属性 的 名 字 引 用 属性 ， 势 必要 通过 套 接 字 传递 属性 的 名 字 给 X 服 务 
器 。 但 是 字符 串 的 数据 量 明 显 大 于 一 个 固定 长 度 的 整数 ， 而 且 ， 还 有 一 
点 ， 字 符 串 的 长 度 是 可 变 的 ， 也 给 协议 的 实现 增加 了 复杂 度 。 为 此 ，X 又 为 
每 个 属性 起 了 个 小 名 ， 这 个 小 名 是 一 个 整 型 数 ， 与 属性 的 名 字 间 是 一 一 对 
应 的 关系，X 将 其 称 为 Atom， 在 应 用 与 服务 右 之 间 通 信 时 ， 使 用 这 个 小 名 
而 不 是 可 变 长 度 的 字符 串 。 


属性 对 应 的 Atom 是 动态 创建 的 ， 当 X 服 务 器 启动 时 ， 会 为 一 些 属性 创 
建 Atom， 其 他 则 是 在 首次 使 用 时 创建 。Xlib 提 供 了 函数 XInternAtoms 和 
XInternAtom 用 来 获取 属性 名 对 应 的 Atom“。 这 两 个 函数 基本 相同 ， 只 不 过 一 
个 是 “批发 ”， 一 个 是 “零售 "， 相 对 于 XInternAtom 而 言 ，XInternAtoms 减 少 


了 应 用 和 服务 器 之 间 的 通信 次 数 。XInternAtoms 函 数 原型 如 下 : 


Status XInternAtoms (Display *display, char **names, int Count ， 
Bool only if exists, Atom *atoms return) 


其 中 ， 参 数 names 包 含 要 转换 的 属性 的 名 称 ，count 表 示 转 换 的 数量 ， 转 
换 后 的 Atom 存 储 在 数组 atoms_returm 中 。 如 果 属 性 的 Atom 已 经 存在 了 ， 则 和 直 
接 获 取 其 值 即 可 ， 和 否则 ， 是 否 为 属性 创建 Atom 要 根据 参数 only_if_exists 的 
值 而 定 。 只 有 only_if_exists 为 False 时 ， 才 创建 Atom。 


Xlib 提 供 了 函数 XGetWindowProperty 和 XChangeProperty 来 读 写 窗口 的 
属性 ， 我 们 以 XGetWindowProperty 为 例 来 讨论 一 下 如 何 读 取 窗 口 属性 ， 该 
函数 原型 如 下 : 


int XGetWindowProperty (Display *display, Window w, Atom property, 
long long offset, long long length, Bool delete, 
Atom req type, Atom actual type return, 
int *actual format return, unsigned long *nitems return, 
unsigned long *bytes after return, 
unsigned char **prop return) 


1) 参数 property 指 的 就 是 准备 读 取 的 窗口 w 的 属性 ， 根 据 该 参数 类 型 也 
印证 了 X 没 有 使 用 属性 的 名 字 ， 而 是 使 用 了 占用 字 世 数 更 少 的 属性 的 
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2) 属性 的 值 可 能 是 一 个 数组 ， 比 如 窗口 管理 器 规范 EWMH 规 定 属性 
_NET_WM_WINDOW_TYPE 值 就 是 一 个 Atom 数 组 。 数 组 就 是 在 内 存 中 的 
一 块 缓冲 区 了 ， 从 这 个 角度 ， 束 比较 容易 理解 参数 long_offset 和 long_length 
的 意义 了 。XGetWindowProperty 为 获取 窗口 属性 提供 了 更 大 的 灵活 性 ， 调 
用 者 可 以 通过 参数 long_offset 和 long_length 读 取 存 储 属性 值 的 缓冲 区 中 指定 
偏 移 处 的 指定 长 度 的 值 ， 这 两 个 参数 均 以 32 位 为 单位 。 
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3) 在 读 取 窗 口 的 属性 后 ， 可 以 通过 参数 delete 告 诉 X 服 务 絮 是 
口 的 这 个 属性 ， 这 也 是 为 了 节省 内 存 空间 考虑 。 


4) XGetWindowProperty 人 允许 调用 者 传递 参数 req_type 告 诉 服 务 器 读 取 
的 属性 值 的 类 型 ， 典 型 的 包括 XA_ATOM、XA_CARDINAL 以 及 
XA_STRING 等 ， 分 别 表示 属性 的 值 为 Atom、32 位 整数 以 及 字符 串 类 型 。 当 
不 确定 属性 的 值 的 类 型 时 ， 可 以 传递 AnyPropertyType 给 X 服 务 右 ， 由 X 服 务 
器 将 实际 的 类 型 通过 参数 actual_type_return 返 回 给 应 用 程序 。 


5) XGetWindowProperty 收 到 X 服 务 器 的 返回 值 后 ， 将 动态 申请 一 块 内 
存 ， 保 存 读 取 到 的 属性 的 值 ， 并 使 用 指针 prop_return 指 回 这 块 内 存 。 有 既然 是 
动态 申请 的 内 存 ， 使 用 后 需要 用 Xlib 的 函数 XFree 将 其 释放 。 


6) XGetWindowProperty 将 实际 读 取 的 属性 的 值 的 类 型 保存 在 
actual_type_return 中 ; 将 实际 读 取 的 属性 的 值 的 格式 保存 在 
actual_format_retum 中 ， 属 性 的 值 的 格式 可 以 是 8、16 或 32 三 者 之 一 ， 分 别 
代表 char、short 以 及 long; 如 有 果 读 取 操 作 仅 读 取 了 保存 属性 值 的 缓冲 区 中 的 
部 分 数据 ， 则 XGetWindowProperty 将 保存 属性 值 的 缓冲 区 中 剩余 的 尚未 读 
取 的 字 节 数 存储 在 bytes_after_return 中 ; nitems_retum 中 记录 的 是 实际 读 取 的 
属性 的 数量 。 


5. 捕 捉 窗 口 


我 们 设想 这 样 一 种 场景 ， 如 图 7-5 所 示 ， 假 设 X 服 务 器 上 已 经 在 运行 两 
个 X 应 用 A 和 B，A 有 是 当前 活动 的 应 用 ，B 和 是 非 活 动 应 用 。B 有 两 个 顶层 窗 


口 ， 除 了 主 窗 口外 ， 打 开 文 件 对 话 框 也 是 一 个 顶层 窗口 ， 同 时 这 个 对 话 杠 
也 是 应 用 B 的 临时 (transient) 窗口 。 正 如 其 字面 意义 所 言 ， 所 谓 

的 "transient" 束 是 临时 的 、 短 暂 的 ， 是 一 个 相对 的 概念 ， 是 相对 于 某 一 窗口 
而 言 的 。 举 个 例子 ， 如 某 些 应 用 的 “打开 文件 ”对 话 框 ， 是 一 个 典型 的 临时 
窗口 。 但 是 如 采 某 个 应 用 的 主 窗口 整 是 一 个 对 话 框 ， 那 么 这 个 对 话 框 束 不 
征 临 时 窗口 了 。 
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图 7-5 切换 应 用 


当 用 户 想 要 将 应 用 B 切 换 为 当前 活动 的 应 用 上 时， 常用 的 方法 之 一 十 使 用 
鼠标 点 击 B 应 用 的 窗口 。 这 时 窗口 管理 瑚 拦截 鼠标 事件 ， 然 后 请 求 X 服 务 大 
重新 排列 窗口 栈 序 ， 具 体 细节 见 7.1.11 节 。 总 之 窗口 管理 器 必须 要 能 接收 到 
姐 标 事件 ， 如 果 接 收 不 到 幢 标 事件 ， 一 切 都 无 从 谈 起 。 


Frame 等 狂 饰 窗口 古 窗 口 管 理 右 创建 的 ， 因 此 窗口 管理 右 可 以 目 如 控 
制 ， 比 如 我 们 可 以 设置 Frame 窗 口 的 事件 掩 码 中 包含 ButtonPressMask。 而 对 
于 应 用 的 顶层 窗口 ， 我 们 肯定 不 能 过 多 和 干涉。 但 十， 我 们 又 不 能 强制 用 户 
一 定 要 点 击 到 Frame 窗 口上 未 被 应 用 顶层 窗口 覆 次 的 地 方 。 而 且 一 般 情 况 
下 ， 用 户 一 定 是 点 击 到 顶层 窗口 或 者 其 子 窗口 上 ， 而 不 是 Frame 窗 口上 ， 毕 
况 Frame 窗 口 未 被 应 用 顶层 窗口 人 遮挡 的 区 域 除 了 标题 栏 外 ， 只 有 很 小 的 边框 
了 ， 也 束 是 说 能 被 点 击 到 的 区 域 很 小 。 


根据 X 的 事件 传播 机 制 ， 如 有 果 发 生 在 一 个 窗口 上 的 事件 未 被 处 理 ， 在 该 
窗口 没有 设置 禁止 事件 继续 向 其 父 窗 口传 播 的 情况 下 ， 事 件 将 沿 着 窗口 树 
一 直 向 着 树 的 根部 传播 。 很 少 有 具有 图 形 界面 的 程序 不 处 理 鼠 标 事件 ， 否 
则 就 没有 任何 意义 了 ， 也 就 是 说 ， 鼠 标 事件 几乎 永远 传递 不 到 Frame 窗 口 ， 
都 被 应 用 目 喘 消化 了 。 如 果 不 能 接收 岂 标 事件 ， 更 何 谈 激活 窗口 了 。 那 么 


皇 么 解决 这 个 问题 呢 ? 


X 提 供 了 鼠标 捕 提 机 制 ， 其 又 分 为 主动 捕捉 和 被动 捕 提 。 以 图 7-5 为 
例 ， 假 设 另 外 一 个 应 用 以 被 动机 制 捕捉 应 用 B 的 顶层 窗口 时 ， 当 用 户 在 应 用 
B 的 顶层 窗口 范围 内 按 下 鼠标 时 ， 将 激活 捕捉 机 制 ，Xx 服 务 句 将 鼠标 事件 不 
再 按照 正 第 的 事件 传播 路 径 传 播 了 ， 而 是 转发 给 捕捉 应 用 B 的 顶层 窗口 的 X 
应 用 。 窗 口 管理 右 恰 恰 是 利用 了 这 个 机 制 ， 捕 捉 非 活动 窗口 ， 从 而 捕获 这 
些 窗 口 的 鼠标 事件 ， 实 现 不 同 应 用 间 的 切换 。 


Xlib 提 供 的 用 于 捕捉 的 函数 是 XGrabButton， 其 原型 如 下 : 


XGrabButton (Display *display, unsigned int button, 


unsigned int modifiers, Window grab window, Bool owner events, 
unsigned int event mask, int pointer mode, 
int keyboard mode, Window confine to, Cursor cursor) 


其 中 各 个 参数 意义 如 下 : 


令 button 表 示 捕 捉 鼠 标 哪个 键 ， 比 如 是 捕捉 左 键 还 是 捕 近 右键 等 。 


令 modifiers 表 示 古 否 要 求 同 时 按 下 键盘 上 某 个 按键 才能 捕捉 ， 也 束 古 我 
们 所 说 的 修饰 键 。 


令 event_mask 表 示 捕 捉 事 件 的 掩 码 ， 即 捕捉 什么 事件 ， 是 捕捉 按 下 鼠标 
事件 还 是 捕捉 释放 鼠标 事件 等 。 


多 confine to 表示 十 否 需 捕捉 的 区 域 限 制 在 某 个 范围 ， 也 就 是 说 ， 当 事 
件 发 生 时 ， 只 有 鼠标 在 这 个 区 域 才 可 以 捕捉 。 


令 cursor 表 示 当 捕捉 发 生 时 ， 是 否 需 要 使 用 特定 的 鼠标 指针 形状 ， 以 给 
用 户 一 个 友好 的 提示 。 


令 owner_events 主 要 是 用 于 当 应 用 捕捉 目 身 创建 的 窗口 时 使 用 ， 与 窗口 
管理 需 无 天 。 


令 参数 grab_window 是 最 核心 的 一 个 参数 ， 理 解 了 这 个 参数 束 基 本 理解 
了 整个 画 数 ， 这 个 参数 吏 是 表明 当 鼠 标 按键 发 生 在 哪个 窗口 时 进行 捕捉 。 


令 最 后 来 解释 参数 pointer_mode。 我 们 举 个 例子 来 解释 这 个 参数 ， 假 设 
我 们 将 捕捉 比喻 为 甸 ， 那 么 捕捉 其 他 窗口 的 应 用 束 古 江 洋 大 盗 ， 被 捕 提 的 
窗口 所 属 的 应 用 束 是 受害 人 。 不 知 读者 是否 有 这 样 的 疑问 : 当 江 洋 大 盗 将 


事件 静 走 后 ， 受 害 人 还 能 否 失而复得 。X 再 次 将 这 个 党 略 性 的 问题 抛 给 了 应 
用 目 己 来 决定 。X 提 供 了 两 种 捕捉 模式 ， 异步 模式 和 同步 模式 。 当 使 用 异步 
模式 时 ， 受 害 人 不 要 心 存 任何 侵 幸 了 。 而 当 使 用 同步 模式 时 ， 在 取消 对 一 
个 窗口 的 捕捉 行为 后 ， 如 采 江 洋 大 盗 民 心 发 现 ，X 则 会 给 他 一 次 浪子 回头 的 
机 会 。 江 洋 大 资 可 以 调用 Xlib 的 函数 XAllowEvents 放 行 这 个 被 截获 的 事件 ， 
这 样 受害 者 束 可 以 失而复得 了 ， 但 是 可 能 不 古 那 么 新 鲜 了， 要 晚 一 点 。 


6.save-set 

笔者 没有 找到 一 个 恰当 一 点 的 词 来 表达 save-set 这 个 术语 ， 所 以 我 们 吏 
直接 用 英文 7。 根据 其 名 字 就 可 以 猜 出 这 是 一 个 集合 了 。 但 是 这 个 集合 是 
做 什么 的 呢 ? 


我 们 设想 这 样 一 种 情况 ， 当 窗口 管理 紫 异 常 终止 时 ， 窗 口 管 理 如 创建 
的 Frame 等 装饰 窗口 自然 也 被 销毁 。 销 毁 这 些 窗口 本 身 没有 问题 ， 但 是 它们 
带 来 了 副作用 : 作为 Frame 窗 口子 窗口 的 应 用 的 窗口 也 被 销毁 。 这 显然 不 是 
我 们 希望 看 到 的 。 


每 个 X 应 用 都 有 一 个 save-set， 其 中 保存 的 就 是 束 是 窗口 的 列表 。 当 应 
用 异常 断 开 到 X 服 务 器 的 连接 时 ，X 服 务 絮 将 首先 检查 应 用 的 save-set， 并 安 
排 根 窗口 领养 save-set 中 的 窗口 ， 从 而 避免 了 在 save-set 中 的 这 些 窗口 被 销 


毁 。 


前 面 提 到 的 窗口 管理 器 的 问题 恰恰 可 以 用 这 个 方法 解决 。 每 当 管理 一 
个 窗口 和 时， 窗口 管理 器 就 可 以 调用 Xlib 的 函数 XAddToSaveSet 将 其 加 入 到 自 


己 的 save-set 中 。 一 旦 当 窗 口 管 理 器 异常 终止 ， 根 窗口 将 领养 应 用 的 窗口 ， 
从 而 避免 了 Frame 窗 口 被 销毁 时 ， 应 用 的 窗口 也 被 销毁 的 命运 。 


7.1.2 创建 编译 脚本 


不 知道 读者 是 否 注意 到 ， 几 乎 前 面 编译 的 所 有 软件 在 进行 安装 时 ， 仅 
仅 通 过 定义 环境 变量 DESTDIR 为 $SYSROOT， 就 安装 到 了 目录 /vita/sysroot 
下 。 如 果 Makefile 全 部 是 由 程序 员 手 工 写 的 ， 不 知道 是 否 能 做 到 如 此 整齐 划 
一 ? 很 多 手写 的 Makefile 中 ， 目 标 install 的 规则 更 多 的 是 形 如 下 面 这 个 样 
于 


NStall 
1nBtall x: /USE/Din 


很 难 考虑 到 像 下 面 这 样 周 全 : 


install: 
install x S$ (DESTDIR) /usr/bin 


因此 ， 标 准 化 的 Makefile 对 GNU 这 种 由 来 自 世 界 各 地 的 程序 员 共 同 参与 
开发 的 项 目 非 常 重要 。 


前 面 ， 我 们 已 经 领教 了 内 核 构 建 系统 中 的 Makefile， 从 其 复杂 程度 可 
见 ， 对 于 具有 多 级 目录 、 多 个 目标 的 复杂 项 目 ， 编 写 和 维护 一 个 Makefile 是 
多 么 党 重 的 一 件 事 情 


鉴于 类 UNIX 系 统 版 本 的 多 样 性 ，GNU 软 件 的 源 代 码 级 的 可 移植 就 变 得 
非常 重要 了 ， 因 此 ， 编 译 脚本 时 必须 要 小 心 应 对 不 同系 统 环 境 之 间 的 差 


异 。 以 我 们 的 环境 为 例 ， 同 样 一 个 软件 ， 在 不 修改 配置 编译 脚本 的 前 提 
下 ， 在 答 主 系统 下 ， 应 该 将 编译 器 识别 为 gcc， 而 在 交叉 编译 环境 下 ， 应 该 
将 编译 絮 识 别 为 686-none-linux-gnu-gcc°。 这 只 是 非常 简单 的 一 个 例子 ， 对 


于 复杂 的 项 目 ， 情 况 要 比 这 个 粳 糙 得 多 。 


于 是 饱 受 折磨 的 开发 者 们 开发 了 GNU 构 建 系统 (GNU Build 
System) ， 或 者 叫 GNU 自 动 构建 工具 (GNU Autotools) ， 为 了 行文 方便 ， 
我 们 简称 其 为 Autotools。Autotools 核 心包 括 Autoconf 和 Automake。 这 里 要 准 
确 理 解 “自动 构建 工具 ”的 意义 ， 所 谓 Autotools， 并 不 是 自动 完成 整个 配置 编 
译 过 程 ， 而 是 自动 构建 配置 脚本 configure 和 Makefile。 


(1) Autoconf 


Anutoconf 的 准确 含义 是 自动 创建 自动 配置 脚本 (automatically create 
automatic configuration scripts) 。 怎 么 理解 自动 配置 脚本 呢 ? 简单 来 讲 ， 就 
是 自动 探测 各 种 不 同系 统 的 各 种 特性 ， 如 是 本 地 编译 还 是 交叉 编译 ， 系 统 
中 使 用 的 编译 器 、 链 接 器 等 程序 是 什么 ， 编 译 以 及 链接 程序 时 需要 的 头 文 
件 、 动 态 库 以 及 它们 所 在 的 路 径 ， 等 等 ， 达 到 自动 动态 适 配 ， 而 不 是 硬 编 
码 到 脚本 中 。 


可 以 这 样 概 括 Autoconf 的 工作 过 程 : 将 多 个 shell 片 段 最 终 合 并 为 一 个 完 
整 的 shell 脚 本 ， 即 configure。Autoconf 使 用 宏 来 定义 这 些 shell 片 段 ， 开 发 者 
需要 根据 编译 需要 ， 使 用 这 些 宏 组 合 Autoconf 的 元 文件 configure.ac， 这 个 元 


文件 曾经 命名 为 configure.in， 后 来 更 改 为 configure.ac， 但 是 Autoconf 也 癌 后 


兼容 configure.in。 然 后 Autoconf 将 元 文件 configure.ac 中 的 安 展开 为 具体 的 配 
置 脚本 configure。 


Autoconf 程 序 本 身 使 用 shell 脚 本 编写 ， 但 是 Autoconf 并 没有 使 用 shell 完 
成 宏 展开 功能 ， 而 是 借助 了 GNU 的 M4 来 完成 宏 的 展开 。 简 单 来 讲 ，M4 就 
是 将 输入 的 宏 名 转换 为 宏 定 义 ， 也 就 是 说 ，M4 的 输入 是 宏 名 ， 而 输出 是 
shell 脚 本 片段 。Autoconf 使 用 M4 定义 了 一 些 内 置 的 宏 ， 并 且 基 于 M4 之 上 广 
封装 了 一 层 宏 ， 目 的 是 为 了 更 符合 Autoconf 的 需求 ，Autoconf 封 装 的 宏一 般 
以 "AC "开头 。 其 他 程序 可 以 使 用 Autoconf 封 装 的 这 些 宏 ， 或 者 直接 使 用 M4 


定义 目 己 的 安 ， 但 是 最 终 ， 本 质 上 都 是 M4 安 。 


因为 M4 安 定义 很 多 是 第 三 方程 序 提供 的 ， 可 能 安装 在 系统 的 多 个 位 
置 ， 因 此 GNU 自 动 构建 系统 编写 了 程序 aclocal 负 责 将 这 些 宏 定义 收集 到 文 
件 aclocal.m4， 你 存在 源码 的 顶层 目录 下 ， 供 目 动 构建 系统 使 用 。 


(2) Automake 


同 Autoconf 类 似 ，Automake 的 准确 含义 是 "automatically generate 
makefile.in"， 开 发 人 员 只 需 编 写 一 个 简单 的 元 文件 ， 在 其 中 描述 必要 的 诉 
求 : 比如 构建 一 个 二 进 制 程序 ， 使 用 的 源 代 码 文件 是 什么 ， 链 搂 某 某 库 等 
即 可 。 其 他 的 都 交 由 Automake 全 权 处 理 吧 。Automake 将 创建 一 个 标准 的 
Makefile 文 件 ， 包 括 补 全 开发 者 不 愿意 编写 的 那些 琐碎 的 规则 ， 如 install、 


clean、 distclean、dist 等 。 


Automake 的 输出 事实 上 是 一 个 Makefile 模 板 ， 命 名 为 Makefile.in。 然 
后 ，configure 脚 本 使 用 探测 到 的 值 奉 换 模板 Makefile.ipn 中 的 变量 ， 创 建 最 终 
的 Makefile。 显然， 这 种 方式 要 比 我 们 将 所 有 的 变量 定义 全 部 硬 编码 到 
Makefile 中 的 做 法 可 移植 性 更 好 。 


综 上 ， 使 用 GNU Autotools 创 建 Makefile 的 过 程 可 以 分 为 如 下 几 个 步 


1) 编写 元 文件 configure.ac 。 


2) 执行 aclocal 。aclocal 将 扫描 configure.ac 中 使 用 的 M4 宏 ， 并 到 系统 中 
收集 这 些 宏 的 定义 ， 然 后 将 这 些 宏 定义 复制 到 源码 顶层 目录 下 的 aclocal.m4 
中 O 〇 


3) 调用 autoconf， 将 configure.ac 中 的 宏 展开 为 shell 脚 本 形式 的 


configure。 
4) 编写 元 文件 Makefile.am 。 


5) 调用 automake。automake 根 据 Makefile.am 创 建 Makefile 的 模板 文件 


Makefile.in。 


6) 执行 脚本 configure。configure 探 测 系统 环境 ， 并 使 用 探测 到 的 值 替 
换 模板 Makefile.ipn 中 的 变量 ， 生 成 具体 的 Makefile 。 


从 上 面 的 讨论 可 以 看 出 ， 对 于 开发 者 来 说 ， 主 要 的 工作 就 是 创建 元 文 
件 configure.ac 和 Makefile.am， 其 他 的 全 部 交 给 Autotools。Autotools 极 大 地 


减轻 了 程序 开发 人 员 的 负担 ， 将 烦琐 的 编写 的 Makefile 任 务 转嫁 给 了 
Autotools 的 开发 和 维护 者 。 


既然 Autotools 有 如 此 多 的 优点 ， 所 以 即使 我 们 的 迷你 窗口 管理 磺 很 
小 ， 我 们 还 是 可 以 借助 它 感 同 吴 受 一 下 Autotools 市 来 的 好 处 。 我 们 这 里 绝 
非 “ 杀 鸡 用 牛刀 ”， 而 是 希望 读者 借助 这 个 例 和 于， 可 以 切 号 体会 一 下 
Autotools， 这 样 无 论 是 在 大 型 项 目 中 使 用 Autotools， 或 者 为 GNU 软 件 页 献 
源码 ， 检 或 基于 使 用 Autotools 的 项 目 进行 二 次 开发 ， 都 会 大 有 益处 。 


1. 创 建 configure 


我 们 将 这 个 迷你 窗口 管理 器 命名 为 winman， 使 用 winman 作 为 顶层 目录 
的 名 字 ， 在 顶层 目录 下 创建 一 个 子 目 录 src 用 来 存放 源 人 代码。 我们 基于 
Xlib， 使 用 C 语 言 编 写 winman。 因此，configure.ac 中 除了 Autoconf 要 求 的 必 
选 的 安 外 ， 最 重要 的 驳 是 检查 C 编 译 器 和 X 的 库 了 ， 其 内 容 如 下 : 


winman/configure .ac : 


AC INIT(winman, 0.1, baisheng wang@163 .Com) 
AM INIT AUTOMAKE (foreign) 


AC PROG CC 
PKG CHECK MODULES (X, x11) 


AC CONFIG FILES (Makefile src/Makefile) 
AC OUTPUT 


Autoconf 要 求 configure.ac 以 安 AC_INIT 作 为 开头 ， 该 安 由 Autoconf 定 
义 ， 接收 一 些 基 本 信息 ， 如 软件 包 的 名 称 ， 版 本 号 ， 开 发 或 者 维护 人 员 的 
Email 等 。 制 作 发 布 的 软件 包 时 ， 将 用 到 这 些 信息 。 


宏 AM_INIT_AUTOMAKE 由 Automake 定 义 ， 用 来 进行 与 Automake 相 关 
的 初始 化 工作 ， 只 要 使 用 Automake， 这 个 宏 也 是 必 选 的 。 在 默认 情况 下 ， 
Automake 会 检查 项 目 目 了 永 中 是 否 包含 NEWS、README、ChangeLog 等 
件 ， 为 简单 起 见 ， 我 们 给 Automake 传 递 了 "foreign" 参 数 ， 明 确 告诉 
Automake 我 们 的 项 目 不 需要 包含 这 些 文件 。 


宏 AC_PROG_CC 用 来 检测 C 编 译 颖 ， 根 据 该 宏 名 的 前 级 "AC_" 就 可 判断 
出 其 他 由 Autoconf 定 义 。 其 将 在 系统 内 搜索 C 编 译 器 ， 并 定义 变量 CC 指 问 搜 
索 到 的 C 编 译 器 。 


接 下 来 ， 我 们 使 用 软件 包 pkg-config 提 供 的 宏 PKG_CHECK_MODULES 
仿 测 X 的 库 。 该 宏 将 定义 两 个 变量 ， 分 别 是 宏 的 第 一 个 参数 加 上 后 
级"_CFLAGS" 和 "_LIBS"， 这 里 就 是 X_CFLAGS 和 X_LIBS。 如 果 查 看 
congfigure 脚 本 就 可 以 发 现 ， 这 个 宏 定义 的 核心 其 实 就 是 执行 命令 "pkg- 


config--cflags x11" 和 "pkg-config--libs x11" ° 


宏 AC_CONFIG_FILES 人 告诉 Automake 生 成 哪些 Makefile 模 板 文件 
Makefile.in。 这 里 ， 需 要 在 顶层 目录 和 src 目 录 下 分 别 创 建 Makefile.in 文 件 。 


在 configure.ac 的 最 后 ，Autoconf 要 求 必 须 以 安 AC_OUTPUT 结 束 


configure.ac ° 


准备 好 configure.ac 后 ， 我 们 使 用 如 下 命令 生成 脚本 configure: 


vita@baisheng:/vita/build/winmans$ aclocal 
vita@baisheng:/vita/build/winmans$ autoconf 


2. 生 成 Makefile 


窗口 管理 器 的 源码 保存 在 顶层 目录 下 的 子 目录 src 中 ， 我 们 在 顶层 目录 
和 子 目 录 src 下 面 分 别 需 要 编写 Automake 元 文件 Makefile.am 。 


顶层 日 录 winman 下 的 Makefile.am 如 下 : 


winman/Makefile .am: 


SUBDIRS = SLC 


因为 项 层 目 好 下 基本 没有 任何 操作 ， 所 以 该 Makefile.am 非 常 侧 单 ， 只 


是 通过 变量 SUBDIRS 告 诉 Automake， 需 要 递归 编译 子 有 目录 src。 


子 目 录 src 下 的 Makefile.am 如 下 : 


winman/stc/Makefile .anm: 
bin PROGRAMS = winman 
winman SOURCES = wm.h main.c 


winman CFLAGS = $(X CFLAGS) 
winman LDADD = $(X LIBS) 


变量 bin_PROGRAMS 指 定 了 编译 最 后 创建 的 二 进 制 可 执行 文件 的 名 
称 ， 该 变量 由 两 部 分 构成 ， 其 中 "bin" 表 示 安 装 在 目录 $prefix/bin 
下 ，"PROGRAMS" 指 明 最 后 创建 的 文件 是 一 个 可 执行 文件 。 


winman SOURCES 表 示 创 建 winman 需 要 的 源 文件 ，winman_CFLAGS 
和 winman_LDADD 分 别 表示 编译 链接 时 需要 传递 给 编译 器 和 链接 器 的 参 


数 。X_CFLAGS 和 X_LIBS 已 经 在 前 面 的 configure.ac 中 由 宏 


PKG_ CHECK _MODULES 定 义 了 。 


Automake 的 元 文件 已 经 准备 就 绕 ， 我 们 使 用 下 面 的 命令 创建 Makefile 的 
模板 Makefile.in: 


vita@baisheng:/vita/build/winman$ automake --add-missing -copy 


其 中 选项 "--add-missing" 和 "--copy" 是 告诉 automake 将 其 需要 的 一 些 脚本 
文件 ， 比 如 install-sh 等 ， 直 接 复制 到 项 目 目 隶 中 ， 而 不 十 建立 这 些 脚 本 文件 
的 链接 。 这 么 做 是 为 了 分 发 到 其 他 系统 时 ， 避 免 因 为 脚本 位 置 不 同 或 者 系 
统 中 没有 安装 相应 脚本 而 导致 编译 链接 失败 。 


上 壕 命 令 执 行 后 ， 将 分 别 在 顶层 目录 和 子 目 隶 src 下 创建 Makefile 的 模板 


Makefile.in。 


最 后 ， 执 行 confugure 脚 本 探测 编译 过 程 所 需 的 各 个 变量 ， 然 后 用 探测 
到 的 具体 的 值 奉 换 Makefile.ipn 中 的 变量 ， 比 如 X_CFLAGS、X_LIBS， 生 成 
Makefile 文 件 : 


vita@baisheng:/vita/build/winman$ ./configure --prefix=/usr 


7.1.3 ”主要 数据 结构 


在 winman 中 ， 将 为 每 个 被 管理 的 窗口 创建 一 个 对 象 ， 记 录 其 相关 信 
轧 ， 为 此 我 们 抽象 了 结构 体 Client。 另 外 ， 我 们 抽象 了 结构 体 WinMan， 其 
中 记录 了 一 些 全 局 信息 。 在 讨论 具体 的 实现 前 ， 我 们 先 来 了 解 一 下 这 两 个 
数据 结构 。 读 者 不 必 全 部 理解 每 一 项 的 含义 ， 后 面具 体 遇 到 时 ， 读 者 可 以 
再 回 到 这 里 ， 前 后 结合 进行 理解 。 


1. 结 构 体 Client 


结构 体 Client 中 主要 包含 窗口 属性 信息 以 及 与 窗口 操作 相关 的 画 数 ， 定 
叉 册 下 : 


winman/src/wm.h: 


typedef struct Client { 
Window window; 
WinMan *wm; 


Window frame; 

Window titlebar; 

Window minimize btn; 

Window maximize restore btn; 
Window close btn; 

Window acting btn; 


Window rsz top side; 
Window rsz bottom side; 


Window rsz lr angle; 
Window resizing area; 


Bool moving; 
int anchor x, anchor y; 


nit Xe Ve WLAN lelghts 

int min width, min height; 

unsigned int state; 

int restore. x, restore 了 restore w, restore h; 


struct ‘Client *trans. fory 
int ignore unmap; 


struct Client *above; 
struct Client *below; 


void (* configure) (struct Client *, XConfigureRequestEvent *) ; 
void (* reparent) (struct Client *); 


void (* move resize) (struct Client *); 
} Client; 


我 们 结合 图 7-6 来 解释 其 中 相关 数据 项 。 


rsz ul angle frame rsz top side minimize btn rsz ur angle 
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图 7-6 窗口 相关 参数 


人 每 个 窗口 作为 X 服 务 器 的 一 个 资源 ， 都 有 一 个 ID 来 唯一 标识 。 这 里 的 
数据 项 window 束 古 被 管理 的 窗口 的 ID 。 


令 wm 指向 全 局 的 结构 体 WinMan 的 对 象 。 


全 frame 是 Frame 窗 口 的 ID; titlebar 是 标题 栏 窗口 的 ID; minimize_btn 是 
最 小 化 按钮 对 应 的 窗口 的 ID; maximize_restore_btn 是 最 大 化 /恢复 按钮 对 应 
的 窗口 的 ID; close_btn 是 天 闭 按钮 对 应 的 窗口 的 ID。acting_btn 是 一 个 为 了 
编程 方便 定义 的 辅助 变量 ， 用 来 记录 用 户 点 击 了 最 大 化 、 最 小 化 以 及 关闭 
按钮 中 的 哪 一 个 。 


以 "rsz_ "resize 的 简写 ) 开头 的 8 个 窗口 ， 是 在 Frame 窗 口上 创建 的 8 
个 不 可 见 窗口 ， 它 们 分 别 位 于 Frame 窗 口 的 4 个 边 和 4 个 角 ， 目 的 是 为 了 便于 
判断 鼠标 是 个 落 在 调整 窗口 太 才 的 区 域 。 也 束 是 说 ， 一 旦 用 户 的 鼠标 落 入 
这 个 窗口 区 域 ， 程 序 的 鼠标 将 使 用 特定 的 指针 ， 提 示 用 户 可 以 进行 改变 窗 
口 的 太 二 了。resizing_area 也 是 一 个 辅助 变量 ， 用 来 记录 鼠标 落 在 了 调整 窗 
口 尺 寸 的 8 个 区 域 的 哪个 区 域 ， 也 就 是 哪个 窗口 上 。 


令 字 量 moving 用 来 标识 用 户 是 否 正在 移动 窗口 ，anchor_x、anchor yi 记 
杂 用 户 在 标题 栏 上 按 下 问 标 左 键 、 准 备 开 始 移 动 时 的 位 置 ， 目 的 是 为 了 计 
算 鼠 标 按 下 位 置 与 当前 位 置 的 距离 。 


令 Xx、y、width、height 记 有 录 窗 口 的 位 置 及 大 小 。min_width、min_height 
表示 人 允许 用 户 改变 窗口 太 寸 时 允许 的 最 小 值 ， 主 要 目的 是 避免 用 户 不 小 心 
将 窗口 缩小 的 太 小 ， 导 致 窗口 “丢失 ”J 。 


令 state 记 孙 窗 口 的 状态 ，winman 只 处 理 最 大 化 及 其 标准 状态 。 
restore_X、restore_y、restore_w、 restore_h 分 别 记录 窗口 在 最 大 化 之 前 的 位 


置 和 尺寸 ， 以 便 从 最 大 化 恢复 为 标准 尺寸 时 使 用 。 


令 trans_for 的 目的 是 为 了 记录 某 个 窗口 是 否 是 临时 窗口 ， 如 果 古 临时 窗 
口 ， 那 么 它 是 谁 的 临时 窗口 。 在 讨论 窗口 切换 上 时， 我 们 将 看 到 这 个 数据 项 
的 意义 。 


令 变量 ignore_unmap 涉 及 的 内 容 有 点 复杂 ， 将 在 7.1.12 节 详细 讨论 。 


多 每 个 窗口 通过 指针 above 和 below 链 接 到 窗口 栈 中 。 


与 窗口 操作 相关 的 一 些 函 数 的 实现 ， 后 面 章节 中 我 们 会 讨论 。 
2. 结 构 体 WinMan 
结构 体 WinMan 中 包含 了 全 局 需要 使 用 的 变量 ， 定 义 如 下 : 


winman/src/wm.h: 


typedef struct WinMan { 
Display *dpy; 
int screen; 
Window root.; 


Atom atoms [ATOM COUNT]; 


struet Client “etack topy 
Struct Client “atack bottom; 
int stack items; 


struct Client *active; 

struct Client *desktop; 

Struct ‘Client *taskbar; 
} WinMan; 


上 述 代码 中 各 个 参数 含义 如 下 : 


令 第 一 个 数据 项 dpy 无 需 多 说 了 ， 它 是 代表 应 用 到 X 服 务 器 的 连接 。 一 
个 XxX 服务 右 可 以 支持 多 屏 ， 每 个 屏 上 都 会 有 一 个 根 窗口 。 虽 然 我 们 不 考虑 多 
屏 的 情况 ， 但 是 某 些 函数 使 用 屏幕 号 和 根 窗口 作为 参数 ， 为 了 避免 每 次 使 


用 时 都 要 从 X 服 务 器 获取 ，winman 在 结构 体 中 保留 了 一 份 副 本 ， 即 数据 项 
screen 和 root， 分 别 代表 屏幕 号 和 根 窗 口 ID 。 


令 数组 atoms 中 记录 的 是 用 于 窗口 间 通 信和 的 Atom，winman 也 不 希望 应 
用 反复 的 从 X 服 务 器 获取 这 些 Atom， 所 以 将 它们 保存 在 winman 的 本 地 。 


令 winman 使 用 栈 的 方式 记录 窗口 对 象 ( 即 为 每 个 窗口 创建 的 结构 体 
Client 的 实例 ) ，stack_top 和 stack_bottom 分 别 指向 这 个 窗口 栈 的 栈 顶 和 栈 
的。 距离 用 户 最 远 的 窗口 记录 在 栈 克 ， 距 离 用 户 最 近 的 窗口 记录 在 栈 顶 。 
stack_items 记 录 栈 中 窗口 对 象 的 数量 。 


令 active、desktop 以 及 taskbar 分 别 指向 当前 活动 的 窗口 、 构 成 保 面 环境 
的 桌面 组 件 以 及 任务 条 组 件 。 


7.1.4 初始 化 


谈 及 初始 化 ， 大 多 给 人 的 印象 是 进行 一 些 琐碎 的 准备 工作 ， 但 是 
winman 中 有 几 处 却 非常 关键 ， 相 关 代码 如 下 : 


winman/src/main.c: 
int, main(int, arge, char “argv [lj) 


{ 


WinMan *wm; 
wm = malloc (sizeof (WinMan) ) ; 
memset (wm, 0, sizeof (WinMan)); 
if (!(wm->dpy = XOpenDisplay (NULL))) { 
} 
wm->screen = DefaultScreen (wm->dpy); 
wm->root = RootWindow (wm->dpy, wm->screen); 
XSetErrorHandler (error handler); 


atom init (wm); 


XSelectInput (wm->dpy, wm->root, SubstructureRedirectMask 
| SubstructureNotifyMask); 


init clients (wm); 
wm event loop (wm); 


return 0; 


下 面 介绍 该 函数 主要 执行 的 操作 。 


(1) 连接 X 服 务 器 


窗口 管理 器 与 普通 的 X 应 用 并 无 本 质 区 别 ， 只 是 具有 一 点 点 特权 ， 它 也 
是 X 服 务 器 的 一 个 客户 端 。 从 服务 器 和 客户 端的 体系 架构 角度 而 言 ， 应 用 程 
序 当然 需要 和 服务 器 建立 连接 后 才能 通信 ， 为 此 ，Xlib 提 供 了 函数 
XOpenDisplay 用 于 建立 它们 之 间 的 连接 。 


(2) 错误 处 理 


Xlib 将 错误 分 为 两 类 : 一 类 错误 是 不 可 恢复 的 ， 这 类 错误 是 致命 的 ， 一 
旦 发 生 后 ， 应 用 基本 不 可 能 执行 下 去 了 ， 如 应 用 程序 和 服务 器 的 连接 断 开 
了 ， 除 了 终止 应 用 程序 外 别 无 选择 ， 男 外 一 类 是 协议 错误 ， 比 如 当 应 用 读 
取 某 个 窗口 的 属性 时 ， 这 个 窗口 可 能 在 服务 占 中 已 经 不 存在 了 。 显 然 ， 这 

错误 不 是 致命 的 ， 应 用 完全 可 以 目 己 决 定 是 忽略 错误 还 是 终止 执行 。 


Xlib 为 这 两 类 错误 都 设置 了 默认 的 错误 处 理 函 数 ， 它 们 的 行为 均 是 打印 
错误 提示 并 终止 应 用 。 但 十 Xlib 也 分 别提 供 了 接口 XSetIOErrorHandler 和 
XSetErrorHandler 允 许 应 用 设置 自己 的 致命 错误 和 协议 错误 处 理 画 数 。 
winman 设 置 了 协议 错误 处 理 函 数 为 error_handler， 当 发 生 协 议 错 误 时 ， 
error_handler 只 打印 错误 信息 ， 并 不 终止 执行 。 


(3) 创建 Atoms 


函数 atom_init 使 用 Xlib 的 函数 XInternAtoms， 一 次 性 创建 后 面 用 到 的 属 
性 的 Atom， 并 将 Atom 保 存在 结构 体 WinMan 的 atoms 数 组 中 。 相 关 代 码 如 
下 : 


winman/src/main.c: 
static void atom init (WinMan *wm) 


{ 


char *atom names[] = { 


"_NET WM WINDOW_ TYPE", 


XInternAtoms (wm->dpy, atom names, ATOM COUNT, False, wm->atoms); 


} 


最 初 ，X 标 准 协 会 制定 了 ICCC 通 信 协 议 。 后 来 ， 随 着 现代 桌面 的 发 
展 ， 又 制定 了 EWMH， 即 对 ICCCM 进 行 的 补充 扩展 。 这 两 个 协议 中 定义 了 
大 量 的 属性 ， 在 函数 atom_init 中 ， 以 WM _ 开 头 的 基本 是 ICCCM 标 准 中 定义 
的 ， 以 _NET 开头 的 是 EWMH 中 定义 的 。 除 了 标准 定义 的 属性 外 ， 应 用 也 
可 以 自 定义 属性 ， 其 中 以 _CUSTOM_ 开 头 的 就 是 winman 自 定义 的 属性 


(4) 拦截 事件 


辑 数 XSelectInput 可 以 说 是 窗口 管理 颖 的 画龙点睛 之 笔 了 。winman 按 照 
前 面 的 讨论 ， 选 择 了 根 窗 口 


的 "SubstructureRedirectMask" 和 "SubstructureNotifyMask" 。 


(5) 管理 已 存在 的 窗口 


在 窗口 管理 器 局 动 之 前 ， 系 统 上 可 能 已 经 有 X 应 用 在 运行 。 因 此 ， 
winman 启 动 时 需要 管理 这 些 已 存在 的 窗口 ， 函 数 init_clients 就 是 做 这 件 事 
的 ， 其 具体 细节 请 参见 7.1.13 广 。 


(6) 事件 循环 


初始 化 完成 后 ， 窗 口 管理 器 进入 事件 循环 ， 函 数 wm_event_loop 调 用 
Xlib 的 函数 XNextEvent 将 窗口 管理 屡 对 X 的 请 求 发 送 给 X 服 务 右 ， 然 后 检查 
事件 队列 ， 调 用 相应 的 事件 处 理 函 数 。 接 下 来 的 的 章节 中 ， 我 们 会 陆续 讨 
论 这 些 事件 处 理 函 数 。 


需要 特殊 指出 的 是 Expose 事 件 ， 以 图 7-7 所 示 窗 口 布局 为 例 。 


Root Window Root Window 
Window A Window B Window A Window B 
一 各 
Window E Window E 


Window C Window D Window C Window D 


图 7-7 多 个 连续 Expose 事 件 发 生 情况 


WindowE 有 四 个 区 域 分 别 被 Window A~D 遮 挡 ， 当 Window E 成 为 当前 
活动 窗口 时 ，X 服 务 器 将 为 每 一 个 被 遮挡 的 部 分 都 报告 一 个 Expose 事 件 ， 并 
将 同一 个 动作 引发 的 Expose 事 件 连续 的 放 到 事件 队列 中 。 结 构 体 
XExposeEvent 中 的 变量 count 就 是 用 来 记录 一 个 Expose 事 件 后 面 还 有 多 少 个 


Expose 事 件 的 


因此 ， 从 效率 的 角度 来 讲 ， 对 于 多 个 连续 的 Expose 事 件 ， 应 用 应 该 名 
略 挤 最 后 一 个 Expose 事 件 前 面 所 有 的 Expose 事 件 ， 而 在 收 到 最 后 一 个 Expose 
事件 时 才 进 行 绘制 。 


715， 为 窗口 “次 户 ” 


A 束 说 明 有 应 用 的 顶层 窗口 请 求 
显示 了 ， 显 然 ， 这 个 时 机 是 窗口 管理 器 切入 的 最 佳 时 机 。winman 百 移 志 历 
窗口 栈 确 认 窗 口 是 否 已 经 被 管理 了 ， 如 果 请 求 映射 的 窗口 尚未 被 管理 ， 则 
调用 wm_new_client 开 始 管 理 窗口 ， 画 数 wm_new_dlient 的 代码 如 下 : 


winman/src/main.c: 


static Client* wm new client (WinMan *wm, Window win) 
{ 

Atom type; 

int format, status; 

unsigned long n, extra; 

Atom *value = NULL; 

Client *c = NULL; 


status = XGetWindowProperty (wm->dpy, win, 
wm->atoms [_NET WM WINDOW TYPE], 
0, 1, False, XA ATOM, &type, &format, &n, 
&extra, (unsigned char **)&value) ; 


if (status == Success && type == XA ATOM 
&& format == 32 && value) { 
if (value[0] == wm->atoms[ NET WM WINDOW TYPE NORMAL]) 
C = normal client new(wm, win); 
else if (value[0] == wm->atoms[_ NET WM WINDOW TYPE DIALOG]) 


} 


Cc->reparent (c); 
c->show(c); 


return c; 


该 函数 执行 的 主要 操作 如 下 : 


1) 如 同 我 们 每 个 人 要 有 一 个 户口 ， 在 落户 时 需要 提供 各 种 自然 人 信息 
一 样 ， 窗 口 管理 器 也 要 收集 窗口 的 各 种 “ 目 然 人 ”信息 ， 为 窗口 在 窗口 管理 


器 中 < 落户”。 


2) 绘制 窗口 装饰 。 


3) 一 切 准 备 妥当 后 ， 申 请 X 服 务 器 显示 应 用 的 窗口 ， 当 然 也 包括 窗口 
管理 右 附 加 的 疤 师 。 


这 一 方 ， 我 们 先 来 讨论 为 窗口 “落户 ”这 一 过 程 。 


如 前 所 述 ， 在 一 个 典型 的 Xx 环境 中 ， 可 能 有 多 种 类 型 的 X 应 用 程序 ， 比 
如 构成 时 面 环境 的 任务 条 等 组 件 ， 以 及 普通 的 应 用 程序 。 即 使 是 普通 的 应 
用 的 窗口 ， 也 可 分 为 标准 的 窗口 以 及 对 话 框 等 。 显 然 ， 不同 的 类 型 的 窗口 
需要 区 别 对 等， 我们 不 能 给 任务 条 也 加 个 标题 栏 ， 那 样 就 会 曾 出 笑话 。 


EWMH 规 定 窗口 需要 设置 属性 _ NET_WM_WINDOW_TYPE 来 表明 自己 
的 类 型 ， 函 数 wm_new_client 依 据 的 束 是 EWMH 这 个 规定 来 判别 窗口 的 类 
型 。 因 此 ， 函 数 wm_new_client 调 用 Xlib 的 函数 XGetWindowProperty 获 取 窗 
口 的 属性 _NET_WM_WINDOW_TYPE 的 值 ， 根 据 窗口 的 不 同类 型 ， 创 建 不 
同类 型 的 窗口 对 象 。 


下 面 ， 我 们 以 标准 窗口 为 例 ， 讨 论 其 “落户 ”过 程 。 


winman/src/normal _ client.c: 


Client* normal client new(WinMan *wm, Window win) 
{ 

Client *es 

XWindowAttributes attr; 

XSizeHints *hints = NULL; 

long dummy; 

Window trans for = None; 


c = mallocl(sizeof (Client)); 
memset (c, 0, sizeof (Client)); 
c->window = win; 

C->wm = wm; 


XSetWindowBorderWidth (wm->dpy, c->window, 0); 
XGetWindowAttributes (wm->dpy, win, &attr); 
C-S>X = attr x 

Cs br 

cc->Swidth = attr.widths; 

c->height = attr.height; 


if (!(hints = XAllocSizeHints())) 
return; 
if (XGetWMNormalHints (wm->dpy, c->window, hints, &dummy)) { 
if (hints->flags & PMinSize) { 
c->min width = hints->min width; 
c->min height = hints->min height; 


} 


XFree (hints) ; 


c->min width = c->min width > MIN WIDTH ? 
c->min width : MIN WIDTH; 

c->min height = c->min height > MIN HEIGHT ? 
c->min height : MIN HEIGHT; 


ewmh get net wm state(c); 
if (c->state & (NET WM STATE MAXIMIZED V 
| NET WM _ STATE MAXIMIZED H)) 
custom get restore size(c); 


XGetTransientForHint (wm->dpy, c->window, &trans for); 
if (trarns fOr) 

c->trans for = wm find client by window(wm, trans for); 
if ‘(Veo=Strans Eor) { 


if (wm->active) { 
XGrabButton (wm->dpy, Buttonl, 0, wm->active->window, 
True, ButtonPpressMask, GrabModeSync, 
GrabModeSync, None, None); 


Item *trans = normal client get transients (wm->active); 
Item *i; 
for (i = trans; i; i = i->next) { 
XGrabButton(c->wm->dpy, Buttonl, 0, 
i->client->window, True, ButtonpressMask, 
GrabModeSync, GrabModeSync, None, None); 


} 


list free(&trans); 


} 


wm->active = c; 
ewmh set net active window (wm->active),; 


} 


c->configure gnormal client configure; 


Cc->reparent = &normal client reparent; 


stack append top(c); 
ewmh update net client list stacking (wm); 


return c; 


下 面 介 绍 函 数 normal_client_new 执 行 的 主要 探 作 。 


通常 ， 窗 口 可 以 请 求 X 服 务 器 绘制 边框 。 但 是 为 了 统一 ， 我 们 调用 
XSetWindowBorderWidth 人 为 地 将 窗口 的 自身 的 边框 设置 为 0， 而 是 在 Frame 
窗口 上 为 被 管理 的 窗口 绘制 统一 的 边框 。 在 winman 中 ， 为 简单 起 见 ， 边 框 
的 宽度 采用 了 一 个 固定 的 值 。 但 是 窗口 管理 器 可 以 尊重 窗口 的 诉求 ， 在 绘 
制 窗口 边框 前 ， 读 取 窗 口 属性 中 设 定 的 边框 宽度 。 


(2) 获取 窗口 几何 尺寸 


接 下 来 ， 我 们 读 取 窗口 的 几何 尺寸 ， 包 括 位 置 、 宽 度 和 高 度 ， 以 及 窗 
口 所 允许 的 最 小 的 尺寸 。 这 里 我 们 分 别 使 用 了 Xlib 的 函数 
XGetWindowAttributes 及 XGetWMNormalHints， 主 要 是 因为 Xlib 不 推荐 通过 
XGetWMNormalHints 获 取 的 窗口 的 位 置 和 大 小 ， 但 是 通过 
XGetWindowAttributes 又 不 能 获取 窗口 的 最 小 宽度 和 最 小 高 度 。 


在 EWMH 中 ， 规 定 了 窗口 的 状态 属性 _NET_WM_STATE 包 括 
_NET WM_ STATE MODAL、 NET WM_ STATE MAXIMIZED VERT、 
_NET WM_ STATE MAXIMIZED HORZ、 


_NET_WM_STATE FULLSCREEN 等 。 


为 简单 起 见 ，winman 中 只 示例 处 理 了 窗口 最 大 化 的 状态 。 函 数 
ewmh_get_net_wm_state 调 用 Xlib 的 接口 XGetWindowProperty 读 取 窗 口 的 属 
性 NET_WM_STATE。 如 果 属 性 中 包含 
_NET WM_STATFE MAXIMIZED VERT 和 


_NET_WM_STATE_MAXIMIZED_HORZ， 那 么 就 说 明 窗口 是 处 于 最 大 化 状 
态 ， 则 winman 党 试 读 取 窗口 中 的 标准 状态 (Restore 状 态 ) 下 窗口 的 位 置 和 
尺寸 信息 ， 以 便 窗口 从 最 大 化 切换 到 标准 状态 时 使 用 。 


读者 可 能 会 问 ， 结 构 体 Client 中 数据 项 restore_x 、restore_y 、restore_w 、 
restore_h 不 是 记录 了 窗口 在 最 大 化 之 前 的 位 置 和 尺寸 吗 ? 但 是 设想 这 样 一 个 
场景 当 窗 口 处 于 最 大 化 时 ， 窗 口 管理 需 异 党 退出 了 ， 那 么 当 窗口 管理 需 
再 次 启动 时 ， 这 个 数据 如 何 初始 化 ? 这 就 是 winman 为 窗口 目 定 义 属性 


_CUSTOM_WM_RESTORE_ GEOMETRY 的 目的 ，winman 将 这 些 信 息 保存 
在 窗口 中 ， 只 要 窗口 在 ， 这 些 信 息 就 可 以 从 窗口 中 读 出 来 ， 可 谓 是 “人 在 阵 


(4) 捕捉 “ 旧 ” 窗 口 


当 新 的 窗口 出 现 后 ， 如 果 这 个 新 窗口 不 是 一 个 临时 窗口 ， 其 将 成 为 当 
前 活动 的 窗口 ， 而 上 一 个 活动 窗口 将 退 居 二 线 。 因 此 ，winman 需 要 捕捉 这 
个 退 居 二 线 的 窗口 ， 以 便 可 以 将 其 顺利 切换 回来 。 而 且 ， 这 个 退 居 二 线 的 
窗口 可 能 还 有 临时 窗口 ， 而 且 临 时 窗口 可 能 还 有 临时 窗口 ， 因 此 ， 玉 数 
normal_client_get_transients 怖 历 窗 口 栈 ， 返 回 这 个 退 居 二 线 窗口 的 临时 窗口 
组 成 的 链 ， 捕 提 这 个 链 上 的 所 有 窗口 。 


(5) 设置 窗口 对 象 的 函数 指针 


创建 了 窗口 对 象 后， 显然 需 要 设置 操作 窗口 的 函数 指针 。 根 据 不 同 的 
窗口 关 型 ， 设 置 这 些 指针 指 癌 不 同 的 男 数 实现 。 对 于 标准 窗口 ， 设 置 这 些 
指针 指向 标准 窗口 的 实现 。 


(6) 更 新 根 窗口 的 属性 


新 窗口 的 “自然 人 ”信息 收集 完毕 后 ， 就 可 以 给 其 “ 沙 户 ”了 了。 函数 
normal_client_new 调 用 stack_append_top 将 新 创建 的 窗口 对 象 压 入 winman 自 
己 维护 的 窗口 栈 。 


为 了 让 其 他 应 用 知晓 又 有 新 成 员 加 入 了 ， 当 然 需 要 更 新 一 些 状态 信 
息 ， 比 如 任务 条 就 时 刻 关注 着 系统 中 应 用 的 变化 情况 。 一 个 是 记录 当前 活 
动 窗口 的 属性 NET_ACTIVE_ WINDOW; 另外 一 个 是 记录 X 服 务 器 中 所 有 


窗口 的 列表 的 属性 NET_CLIENT_LIST_STACKING。 这 两 个 属性 都 是 
EWMH 标 准 规定 的 ， 它 们 都 是 根 窗口 的 属性 。 画 数 normal_client_ new 中 调用 
的 两 个 子 函 数 ewmh_set_net_active_window 和 


ewmh_update_net_client_list_stacking 日 的 就 是 分 别 更 新 这 两 个 属性 。 


7.1.6 ”构建 窗口 半 师 


仅 给 窗口 “落户 ”还 是 不 够 的 ， 接 下 来 我 们 还 需要 为 窗口 构建 装饰 。 除 
了 起 到 美化 作用 外 ， 这 些 闭 饰 还 是 用 户 和 应 用 的 窗口 之 间 的 桥梁 。 用 户 可 
以 通过 标题 栏 移动 窗口 位 置 ， 可 以 通过 边框 改变 窗口 尺寸 ， 可 以 扩 击 最 大 
化 按钮 将 窗口 最 大 化 ， 可 点击 最 小 化 按钮 将 窗口 最 小 化 ， 可 以 点 击 关 闭 按 
钮 关闭 窗口 。 


在 创建 了 窗口 对 象 后 ， 玉 数 wm_new_dlient 中 调用 窗口 对 象 中 函数 指针 
reparent 指 癌 的 范 数 来 构建 窗口 装饰 。 对 于 标准 窗口 来 说 ， 构 建 窗口 攻 饰 的 
函数 是 normal_client_reparent， 代 码 如 下 : 


winman/src/normal client.c: 


static void normal client reparent (Client *c) 


{ 


XSetWindowAttributes attr; 
WinMan *wm = CcC->wm; 

int frame x, frame y; 
KEOLOF te, Re 


if (normal client calc geometry(c)) 
XMoveResizeWindow (wm->dpy, c->window, CcC->x, C->Yy, 
c->width, c->height); 


XAllocNamedColor (wm->dpy, DefaultColormap (wm->dpy, 
wm->screen), LIGHTGRAY, &sc, &tc); 


attr.background pixel = sc.pixel; 

attr,.override redirect = True; 

attr.event mask = SubstructureRedirectMask 

| SubstructureNotifyMask 

| ExposureMask 

| ButtonPressMask 

| ButtonReleaseMask 

| Buttonl1MotionMask: 

c->frame = XCreateWindow (wm->dpy, wm->root, 
C->X - BORDER WIDTH, 
C->y - BORDER WIDTH - TITLEBAR HEIGHT, 
c->width + BORDER WIDTH * 2, 
c->height + TITLEBAR HEIGHT + BORDER WIDTH * 2, 
CopyFromParent, CopyFromParent, CopyFromParent, 
CWOverrideRedirect | CWwBackPixel | CWEventMask, 
&attr),; 

XDefineCursor (wm->dpy, c->frame, 

XCreateFontCursor (wm->dpy, XC arrow)); 


attr.event mask = ExposureMask; 
c->titlebar = XCreateWindow(...); 


Cc->rsz ul angle = XCreateWindow (wm->dpy, c->frame, 
0, 0, RSZ ANGLE SIZE, RSZ ANGLE SIZE, 0, 
CopyFromParent, InputOonly, CopyFromParent, 
CWOverrideRedirect, &attr); 


XDefineCursor (wm->dpy, c¢->rsz ul angle, 
XCreateFontCursor (wm->dpy, XC ul angle)); 


XLowerWindow (wm->dpy, c¢->rsz ul angle); 


XAddToSaveSet (wm->dpy, c->window); 


XReparentWindow (wm->dpy, c->window, c->frame, BORDER WIDTH, 
TITLEBAR HEIGHT + BORDER WIDTH); 


函数 normal_client_reparent 执 行 的 主要 操作 如 下 : 


(1) 调整 窗口 位 置 和 尺寸 


在 显示 窗口 前 ，winman 调 用 函数 normal_client_calc_geometry 对 窗口 的 
位 置 和 尺寸 进行 了 一 些 合理 性 检查 。 对 于 某 些 不 合理 的 值 ， 函 数 
normal_client_calc_geometry 会 进行 简单 的 修正 ， 比 如 不 能 允许 窗口 显示 在 
屏幕 的 可 见 范围 之 外 。 如 采 经 过 函数 normal_client_calc_geometry 计 算 发 现 
窗口 确实 需要 修正 ，normal_dlient_reparent 则 调用 Xlib 的 函数 
XMoveResizeWindow 请 求 X 服 务 硕 对 窗口 进行 调整 。 


(2) 创建 Frame 窗 口 


正 所 谓 “ 皮 之 不 存 ， 毛 将 在 附 ”"，Frame 作 为 承载 窗口 装饰 的 载体 ， 
normal_client_reparent 首 完 调 用 Xlib 的 函数 XCreateWindow 来 创建 这 个 窗口 。 
Frame 的 父 窗 口 是 根 窗口 ， 几何 尺寸 基于 应 用 的 顶层 窗口 的 尺寸 ， 并 为 容纳 

边框 以 及 标题 栏 等 预 留 出 空间 ; 其 他 如 窗口 类 型 等 属性 均 采用 与 根 窗 
口 相 同 的 值 即 可 ， 世 束 是 代码 中 的 为 五 数 XCreateWindow 传 递 参数 
CopyFromParent 的 意图 。 


winman 通 过 结构 体 XSetWindowAttributes 设 置 了 Frame 窗 口 的 另外 三 个 


属性 : override_redirect、background_pixel 和 event_mask 。 


override_redirect 表 示 窗 口 是 否 接受 窗口 管理 。Frame 窗 口 ， 包 括 后 面 的 
标题 栏 等 其 他 装饰 窗口 ， 当 然 不 再 需要 窗口 管理 器 管理 ， 因 此 ， 这 个 属性 
设置 为 True。 


X 服 务 器 中 可 以 创建 一 个 或 者 多 个 颜色 映射 (Colormap) ， 每 个 颜色 了 映 
册 束 是 一 个 数组 ， 数 组 中 的 每 个 元 取代 表 一 个 上 颜色。 颜色 映射 数组 的 大 
小 ， 由 显示 亏 的 色 深 决定 。 应 用 使 用 颜色 时 ， 首 先 要 根据 颜色 的 名 字 ， 在 
颜色 映 里 中 找到 对 应 的 索引 ，X 将 这 个 过 程 称 为 分 配 颜 色 如 图 7-8 所 示 。 


Colormap 


图 7-8 XX 颜色 映射 


函数 normal_client_reparent 使 用 Xlib 的 函数 XAllocNamedColor 分 配 了 一 
个 颜色 ， 然 后 将 这 个 颜色 通过 属性 background_pixel 指 定 为 Frame 窗 口 的 背景 
色 。 


winman 通 过 属性 event_mask 选 择 接收 Frame 窗 口 的 事件 。winman 依 然 需 
要 拦截 应 用 的 顶层 窗口 的 请 求 、 获 取 它 们 的 某 些 通知 ， 而 应 用 的 顶层 窗口 


已 经 成 为 Frame 的 子 窗口 了 ， 所 以 winman 需 要 接收 Frame 的 子 窗口 的 事件 ， 
这 束 是 选择 Frame 窗 口 的 事件 掩 码 SubstructureRedirectMask 和 
SubstructureNotifyMask 的 目的 。Frame 窗 口 也 需要 绘制 ， 所 以 选择 了 
ExposureMask。 事 件 掩 码 中 最 后 选择 接收 的 就 是 几 个 鼠标 事件 ，winman 按 
照 下 面 的 逻辑 处 理 Frame 及 作为 其 子 窗口 的 各 个 装饰 窗口 间 的 鼠标 事件 。 


winman 仅 接收 Frame 的 鼠标 事件 ， 而 不 接受 其 他 装饰 窗口 的 姐 标 事件 。 
所 以 ， 当 鼠标 事件 发 生 在 任何 装饰 窗口 上 时 ， 按 照 X 的 事件 传播 机 制 ， 鼠 标 
事件 最 终 都 会 在 窗口 树 中 同上 传播 到 Frame。 也 就 是 说 ，winman 最 终 接收 到 
的 是 来 目 Frame 窗 口 的 鼠标 事件 ， 鼠 标 事件 中 的 参数 window 十 Frame， 但 是 
subwindow 则 是 鼠标 事件 发 生 时 ， 鼠 标 指 针 所 在 的 真实 的 奢 饥 窗口 。 后 面 ， 
当 处 理 鼠 标 事 件 时 ，winman 就 是 利用 鼠标 事件 的 参数 subwindow 判 断 发 生 在 
哪个 窗口 装饰 上 了 ， 从 而 判读 出 用 户 的 意图 ， 比 如 是 关闭 窗口 ， 最 小 化 窗 
口 ， 抑 或 是 移动 窗口 等 。 


(3) 设置 Frame 窗 口 鼠 标 指针 形状 


Xlib 提 供 了 郴 数 XDefineCursor 为 窗口 设置 鼠标 指针 的 形状 ，winman 将 
Frame 窒 口 的 指针 设置 为 XC_arrow， 即 稼 用 的 箭头 形状 。 


(4) 创建 标题 栏 、 最 大 化 、 最 小 化 及 关闭 按钮 


winman 为 这 几 个 窗口 装饰 分 别 创建 了 窗口 ， 基 本 与 创建 Frame 窗 口 相 
同 。 它 们 的 父 窗口 是 Frame 窗 口 。winman 只 接收 这 几 个 窗口 的 Expose 事 件 ， 


毕竟 还 需要 在 按钮 上 绘制 图 标 。winman 也 无 需 为 这 几 个 窗口 定义 鼠标 指 
针 ， 它 们 使 用 与 父 窗 口 Frame 相 同 的 鼠标 指针 。 


(5) 创建 “改变 窗口 尺寸 ”指示 区 域 


接 下 来 winman 还 要 创建 几 个 幕后 英雄 ， 即 前 面 提 到 的 以 rsz_ 开 头 的 几 
个 窗口 。 这 几 个 窗口 的 目的 非常 单纯 ， 就 是 为 了 当 鼠 标 进入 这 个 区 域 时 ， 
显示 特殊 的 鼠标 指针 形状 ， 提 示 用 户 可 以 在 这 个 区 域 改 变 窗口 太 寸 了 。 


这 几 个 窗口 不 需要 显示 任何 内 容 ， 因 此 窗口 的 类 型 设置 为 InputOnly; 
而 且 也 不 需要 接收 任何 事件 ， 所 以 无 须 设 置 任何 事件 掩 码 ; 它们 也 不 需要 
接受 窗口 管理 器 管理 ， 所 以 窗口 属性 override_redirect 设 置 为 True 。 


为 了 给 用 户 一 个 直观 的 提示 ， 这 几 个 窗口 的 鼠标 指针 分 别 设置 为 不 同 
的 形状 ， 比 如 窗口 正 上 方 的 鼠标 指针 设置 为 XC_top_side， 左 上 角 设 置 为 


XC_ul_angle， 等 等 。 


对 于 位 于 四 个 角 的 窗口 ，winman 还 调用 了 Xlib 的 函数 XLowerWindow， 
其 目的 是 什么 呢 ? 图 7-9 展 示 了 放大 了 的 窗口 右上 角 的 区 域 ， 窗 口 
rsz_Ur angle 是正 方形 形状 的 窗口 ， 但 是 我 们 希望 鼠标 指针 只 有 落 在 图 中 使 
用 灰色 标 出 的 区 域 时 才 允 许 用 户 改变 窗口 太 寸 。 并 且 窗 口 rsz_ur angle 不 应 
该 遮挡 关闭 按钮 ， 导 致 其 失效 ， 因 此 winman 使 用 XLowerWindow 将 
rszZ_ur_angle 置 于 窗口 栈 的 底部 ， 以 免 遮 挡 其 他 兄弟 窗口 。 


rszZ_uUr_ angle 


图 7-9 放大 的 窗口 右上 和 角 区 域 
(6) 将 应 用 顶层 窗口 加 入 save-set 


如 前 面 讨论 的 ， 我 们 不 希望 winman 异 常 退 出 时 ， 因 为 销 贤 Frame 帘 口 而 
导致 作为 Frame 子 窗口 的 应 用 的 顶层 窗口 也 受 牵 连 ， 因 此 winman 调 用 Xlib 的 
函数 XAddToSaveSet 将 应 用 的 顶层 窗口 加 入 到 save-set 中 。 


如 果 读 者 注释 掉 函 数 normal_client_reparent 中 的 XAddToSaveSet， 然 后 
尝试 终 止 窗口 管理 器 ， 就 会 发 现 应 用 的 窗口 也 随 之 被 销 山 了 。 


当 save-set 中 的 窗口 被 销毁 时 ，X 服 务 吕 负责 从 save-set 中 将 它们 移 除 。 
因此 ， 当 应 用 的 顶层 窗口 “扬长 而 去 ?时 ，winman 无 需 调 用 


XRemoveFromSaveSet 从 save-set 中 移 除 它们 。 


(7) 将 应 用 的 顶层 窗口 作为 Frame 的 子 窗口 


Frame 窗 口 以 及 作为 其 子 窗口 的 其 他 装饰 ， 全 部 准备 完毕 。 最 后 ， 函 数 
normal_client_reparent 调 用 Xlib 的 XReparentWindow 函 数 将 Frame 作 为 应 用 的 
顶层 窗口 的 父 窗口 ， 完 成 最 后 一 击 。 


7.1.7 ”绘制 装饰 突 口 


在 7.1.6 市 中 ，winman 创 建 了 各 个 装饰 窗口 ， 但 是 并 没有 为 各 装饰 窗口 
绘制 内 容 。 事 实 上 ， 即 使 winman 想 去 绘制 ， 也 是 有 心 无 力 。 基 于 X 的 原 
理 ，X 服 务 妖 并 不 保存 窗口 的 内 容 ， 在 窗口 可 见 时 ，X 服 务 器 会同 应 用 报告 
Expose 事 件 ， 应 用 收 到 这 个 事件 后 ， 开 始 绘制 。 否 则 即使 应 用 在 创建 窗口 
时 目 说 目 话 地 进行 了 绘制 ， 也 会 被 丢掉 。 


因此 ， 在 函数 wm_new_client 中 ， 在 构建 了 窗口 装饰 后 ， 调 用 了 窗口 对 
象 中 函数 指针 show 指 回 的 函数 ， 请 求 X 服 务 右 进行 显示 。 对 于 标准 窗口 来 
说 ， 请 求 色 服务 器 显示 窗口 是 normal_client_show， 代 码 如 下 : 


winman/src/normal client.c: 


static void normal client show(Client *c) 


{ 


WinMan *wm = C->wm; 


XMapWindow (wm->dpy, c->frame); 
XMapSubwindows (wm->dpy, Cc->frame); 


在 接受 了 winman 的 显示 请 求 后 ，X 服 务 器 将 同 winman 发 送 Expose 事 
件 。 收 到 Expose 事 件 后 ，winman 将 绘制 窗口 装饰 。 标 准 窗口 的 处 理 Expose 
事件 的 函数 如 下 ; 


winman/src/normal client.c: 


static void normal client redraw(Client *c) 


WinMan *wm = C->wm; 
GC gc = XCreateGC (wm->dpy, wm->root, 0, 0); 


Pixmap cm close = XCreateBitmapFromData (wm->dpy, wm->root, 
close bits, close width, close height); 


XSetForeground (wm->dpy, gc, BlackPixel (wm->dpy, wm->screen)); 


draw raised(wm, c->titlebar, 0, 0, 
c->width - TITLEBAR HEIGHT * 3, TITLEBAR HEIGHT); 
draw raised(wm, c->close btn, 0, 0, TITLEBAR HEIGHT, 
TITLEBAR HEIGHT) 2 
XSetClipMask (wm->dpy, gc, cm close); 
XSetClipOorigin(wm->dpy, gce, 2, 2); 
XFillRectangle(wm->dpy, c=>close btn, gc, 0, 0, 
TITLEBAR HEIGHT, TITLEBAR HEIGHT) 让 
XSetClipMask (wm->dpy, gc, None); 
draw raised(wm, c->frame, 0, 0, c->width + BORDER WIDTH * 2, 
c->height + TITLEBAR HEIGHT + BORDER WIDTH * 2); 
draw_ lowered (wm, c->frame, BORDER WIDTH - 2, BORDER WIDTH - 2, 
c->width + 3, TITLEBAR HEIGHT + c->height + 3); 


XFreeGC (wm->dpy, gc); 


该 函数 执行 的 主要 操作 如 下 : 
1) 为 标题 栏 绘 制 边框 ， 使 标题 栏 看 上 去 更 富 立 体感 。 


2) 为 标题 栏 上 的 关闭 等 各 个 按钮 绘制 图 标 ， 并 为 它们 也 绘制 边框 。 


事实 上 ， 上 所谓 的 绘制 边框 就 是 在 窗口 边 上 绘制 线条 ， 但 是 不 同 的 线条 
使 用 不 同 的 颜色 ， 依 据 色 差 来 产生 立体 感 。 画 数 draw_raised 和 draw_lowered 
束 是 做 这 件 事 的 。 


对 于 标题 栏 上 关闭 等 按钮 的 图 标 ，winman 使 用 了 类 似 掩 码 的 方法 来 给 
制 。 以 函数 XFillRectangle 为 例 ， 在 默认 情况 下 ， 将 使 用 图 形 上 下 文 (GC) 
中 指定 的 前 景色 填充 矩形 。 但 是 ， 如 条 设 置 了 GC 中 的 clip_mask， 那 么 
clip_mask 中 凡是 值 为 “1 的 位 ， 依 然 使 用 前 景色 填充 ， 但 是 值 为 "0 的 位 则 不 
会 进行 填充 ， 如 图 7-10 所 示 。 
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图 7-10 ”dlip_mask 使 用 示意 图 


7.1.8 配置 窗口 


， 我 们 在 编写 具有 图 形 界 面 的 应 用 程序 时 ， 在 显示 图 形 界面 之 
前 ,一定 会 设置 窗口 的 位 置 、 尺 寸 或 者 边框 宽度 等 。 叶 然 读者 可 能 反 驱 
说 ， 我 们 有 时 并 没有 设置 这 些 啊 ? 实际 上 ， 那 是 因为 如 GTK、QT 等 图 形 库 
己 经 帮 我 们 做 了 。 男 外 一 种 情况 是 在 应 用 运行 的 某 个 中 间 时 刻 ， 应 用 也 可 
能 会 改变 窗口 的 这 些 信 息 。 


X 将 这 些 信 息 统称 为 窗口 配置 ， 包 括 窗 口 的 位 置 、 宽 度 和 高 度 ， 边 框 的 
宽度 以 及 在 栈 中 的 位 置 。 


在 上 述 两 种 情况 下 ， 应 用 都 将 产生 配置 请 求 ，X 服 务 絮 也 都 会 将 它们 重 
定 癌 给 窗口 管理 右 。 那 么 窗口 管理 絮 如 何 区 分 这 两 种 情况 呢 ?winman 是 这 
样 处 理 的 ， 当 收 到 X 服 务 右 重 定 同 来 的 配置 请 求 时 ，winman 调 用 函数 
wm_find_client_by_window 授 历 窗 口 栈 ， 如 果 窗 口 栈 中 没有 一 个 窗口 对 象 与 
发 送 请 求 的 窗口 匹配 ， 殉 说 明 这 个 窗口 尚未 被 管理 ， 否 则 说 明 这 个 窗口 已 
经 被 管理 了 。 


对 于 尚未 纳入 管理 的 应 用 的 窗口 ，winman 当 然 不 能 贸然 管理 ， 谁 知道 
未 来 它 是 否 需 要 管理 呢 。 所 以 直接 请 求 X 服 务 器 满足 其 需要 。winman 从 事 
件 XConfigureRequestEvent 中 提取 信息 ， 不 加 任何 修改 ， 完 全 照搬 原来 的 配 
置 请 求 ， 使 用 Xlib 的 函数 XConfigureWindow 直 接 代替 应 用 向 X 服 务 器 发 出 配 
置 请 求 。 


对 于 已 被 管理 的 窗口 ，winman 调 用 具体 窗口 对 象 中 处 理 配置 的 函数 进 


行 具体 的 配置 。 相 关 代 码 如 下 : 


winman/src/main.c: 


static void wm handle configure request (WinMan *wm, 


XConfigureRequestEvent *e) 
Client ey 
XWindowChanges xwc; 
int border width; 
int screen width, screen height; 


c = wm find client by window(wm, e->window); 


| 
XAWCS 人 三 已 二 2 区 
XWC,Y = ee->yY; 


xwc.width = e->width,; 


XConfigureWindow (wm->dpy, e->window, e->value mask, &xwc); 


} else 
c->configure l(c, e); 


return,; 


我 们 看 到 ， 当 winman 不 了解 “敌情 ”时 ， 它 直接 调用 Xlib 的 函数 


XConfigureWindow 将 “皮球 ”又 踢 给 了 X 服 务 器 。 


而 对 于 已 经 在 目 己 掌控 之 下 


的 窗口 ， 则 调用 具体 窗口 对 象 的 配置 处 理 函 数 进 行 配置 。 以 标准 窗口 对 象 
为 例 ， 函 数据 针 configure 指 加 normal_client_configure， 其 代码 如 下 : 


winman/src/normal _ client.c 


static void normal client configure (Client *c, 
XConfigureRequestEvent *e) 


if (e->value mask & CWX) 
GD = =x 


if (e->value mask & (CNX | CwY | Cwwidth | CwHeight)) { 


normal client calc geometry(c); 
c->move resize(c); 


static void normal client move resize(Client *c) 
WinMan *wm = CcC->wm; 
XMoveResizeWindow (wm->dpy, c->frame, ...); 


XMoveResizeWindow (wm->dpy, c->window, ...); 
XMoveWindow (wm->dpy, c->close btn, ...); 


该 男 数 的 核心 就 是 调用 Xlib 的 XMoveResizeWindow 系 列 函 数 ， 满 足 窗 
口 的 配置 请 求 。 但 是 有 一 点 需要 注意 ， 因 为 应 用 的 顶层 窗口 的 配置 改变 
了 ， 所 以 所 有 的 窗口 装饰 可 能 都 需要 进行 调整 。 


7.1.9 ”移动 窗口 


对 于 一 个 典型 的 介面 应 用 来 说 ， 用 户 可 以 通过 拖 动 窗口 的 标题 栏 来 移 
动 窗口 。 这 里 所 请 的 “ 拖 动 * 的 具体 动作 是 ， 在 标题 栏 上 按 下 鼠标 左 键 并 保 
持 ， 然 后 移动 鼠标 ， 直 到 释放 鼠标 。 


因此 ， 整 个 移动 窗口 的 过 程 可 以 划分 为 三 个 阶段 : 
1) 用 户 在 标题 栏 上 按 下 鼠标 左 键 并 保持 ; 

2) 用 户 移 动 姐 标 ; 

3) 用 户 释 放 鼠 标 ， 移 动 结束 。 


为 此 ， 结 构 体 Client 中 设计 了 布尔 变量 moving， 当 用 户 在 标题 栏 内 按 下 
鼠标 左 键 时 ，moving 将 被 置 为 True。 当 鼠标 移动 事件 发 生 时 ， 如 果 变 量 
moving 为 True， 那 么 我 们 束 可 以 断定 用 户 是 在 移动 窗口 。 一 旦 用 户 释放 了 


鼠标 ，winman 将 moving 更 改 为 False。 


1. 按 下 鼠 标 


一 旦 收 到 幢 标 按 下 事件 ，winman 首 先 要 找到 幢 标 事件 发 生 在 哪个 窗口 
对 象 上 ，winman 中 封装 的 函数 wm_find_client_by_frame 就 是 做 这 件 事 的 。 找 
到 了 具体 的 窗口 对 象 后 ， 则 调用 这 个 窗口 对 象 的 指针 button_press 指 同 的 函 
数 ， 代 码 如 下 : 


winman/src/main.c: 


static void wm handle button press (WinMan *wm, XButtonEvent *e) 


{ 


Client *ce; 


if (c = wm find client by frame (wm, e->window)) 
c->button press(c, e); 


我 们 还 是 以 标准 窗口 对 象 为 例 ， 其 处 理 鼠 标 按 下 事件 的 函数 是 
normal_client_button_press ， 代 码 如 下 : 


winman/src/normal client.c: 


static void normal client button press(Client *c, XButtonEvent *e) 


{ 


} else if (e->subwindow == c->titlebar) { 
Cc->moving = True; 
Cc->anchor x = e->x; 
Cc->anchor y = e->y:; 

} else if (e->subwindow == c->rsz top side 


函数 normal_client_button_press 检 查 鼠 标 事 件 中 的 成 员 subwindow 是 否 是 
标题 栏 ， 如 果 是 ， 则 设置 窗口 对 象 的 moving 为 True。 读 者 可 能 有 个 疑问 ， 
如 果 用 户 只 是 虚 晃 一 枪 ， 马 上 又 释放 了 鼠标 呢 ? 那 也 没有 什么 影响 ， 因 为 
winman 在 鼠标 释放 的 事件 处 理 函 数 中 ， 将 把 这 个 值 重 置 为 False。 


同时 ， 函 数 normal_client_button_press 将 鼠标 事件 发 生 的 位 置 记录 到 窗 
口 对 象 中 的 anchor_ x 和 anchor_ y 中 。 注 意 ，winman 记 录 的 位 置 使 用 的 是 窗口 
内 部 坐标 ， 是 相对 于 窗口 原点 的 。 后 面 将 以 这 个 点 为 参考 ， 计 算 窗 口 移动 
后 的 新 位 置 。 


2. 移 动 忌 标 


在 收 到 鼠标 移动 通知 后 ，winman 首 先 还 是 要 找到 具体 的 窗口 对 象 ， 
后 调用 这 个 帘 口 的 函数 指针 motion 指 辐 的 函数 ， 代 码 如 下 : 


winman/src/main.c: 
static void wm handle motion notify(WinMan *wm, XMotionEvent *e) 


Client *c = wm find client by frame (wm, e->window); 


iF(e) 
c->motion(c, e); 


以 标准 窗口 对 象 为 例 ， 其 处 理 鼠 标 移 动 事件 的 函数 是 
normal_client_motion， 代 码 如 下 : 


winman/src/normal client.c: 


void normal client motion(Client *c, XMotionEvent *e) 
WinMan *wm = CcC->wm; 
nt Ey YY WIdERn;: lerght; 
int frame x, frame yy; 


if (c->moving) { 
frame x = e->x root - c->anchor x; 
frame Y = e=>y rooOt = C==anchor YY; 


XMoveWindow (wm->dpy, c->frame, frame x, frame y); 


} else if (c->resizing area) { 


函数 normal_client_motion 首 先 检查 窗口 对 象 中 的 变量 moving。 如 果 


~ 


BN 


moving 为 True， 则 说 明 用 户 正在 拖 动 标题 栏 。 因 此 ， 其 根据 当前 的 鼠标 所 


在 的 位 置 以 及 在 鼠标 按 下 时 所 在 的 位 置 ， 即 窗口 对 象 中 的 变量 anchor_x 和 
anchor y， 计 算出 窗口 新 的 位 置 ， 具 体 的 计算 方法 参见 图 7-11。 然 后 调用 
Xlib 的 函数 XMoveWindow 移 动 窗口 。 


root y - anchor y 


Root Window 


看 过 上 面 的 实现 ， 读 者 可 


root x - anchor x ¥_ anchor x 
anchor yj | ls | | 
一 | 1 国医 
root x | | 


图 7-11 窗口 移动 位 置 计算 


能 会 有 个 疑问 ， 一 定 要 设置 moving 吗 ? 不 可 


以 在 移动 时 根据 事件 中 的 子 窗口 (subwindow) 是 否 是 标题 栏 来 判断 是 否 是 
在 拖 动 标题 栏 吗 ? 即将 下 面 的 语句 : 


if (c->moving) 


更 改 为 : 
if (e->subwindow == Cc->titlebar ) 


答案 是 不 可 以 。 原 因 是 ， 如 采 有 鼠标 移动 较 慢 ， 那 么 在 移动 时 四 标 指针 
会 一 直 落 在 标题 栏 中 ， 这 没有 问题 。 但 是 如 采用 户 移动 得 非常 快 ， 窗 口 移 
动 的 速度 跟 不 上 鼠标 ， 这 时 鼠标 所 在 的 子 窗口 ， 即 鼠标 移动 事件 中 的 成 员 
subwindow， 或 者 是 0， 或 者 是 其 他 窗口 ， 总 之 ， 不 再 是 标题 栏 了 


3. 释 放 鼠 标 


在 收 到 鼠标 释放 事件 后 ，winman 首 移 找 到 具体 的 窗口 对 象 ， 然 后 调用 
这 个 窗口 的 函数 指针 button_release 指 向 的 函数 ， 代 码 如 下 : 


winman/src/main.c: 
static void wm handle button release(WinMan *wm, XButtonEvent *e) 


Client *c = wm find client by frame (wm, e->window); 


.Ee) 
c->button release(c, e); 


以 标准 窗口 对 象 为 例 ， 其 处 理 鼠 标 释 放 事 件 的 函数 是 


normal _client_button_release， 代 码 如 下 : 


winman/src/normal _ client.c : 
static void normal client button release (Client *c, 


XButtonEvent *e) 


} else if (c->moving) { 
C->moving = False; 
} else if (c->resizing area) { 


当 鼠 标 释放 时 ， 表 明 用 户 已 经 停止 移动 窗口 ，winman 将 窗口 对 象 中 的 


moving 标 志清 除 。 


7.1.10 ”改变 窗口 大 小 


改变 窗口 大 小 与 移动 窗口 的 操作 逻辑 上 基本 相同 ， 这 里 只 人 简要 讨 
论 实 现 的 逻辑 ， 驶 不 再 列 出 具体 代码 了 ， 请 读者 目 行 参 考 随 书 光 盘 中 
附 融 的 源 代码 。 


在 用 户 按 下 鼠标 事件 时 ， 将 鼠标 指针 所 在 的 标识 移动 区 域 的 窗 
口 ， 也 就 是 结构 体 Client 中 以 rsz_ 开 尖 的 窗口 ， 记 有 杂 到 窗口 对 象 的 成 员 


resizing_area 中 。 


然后 ， 当 收 到 鼠标 移动 事件 时 ， 如 采 窗 口 对 象 的 成 员 resizing_area 
非 0， 那 惑 说 明 用 户 正 在 试图 改变 窗口 大 小 。 根 据 resizing_area 与 8 个 标 
识 移动 区 域 的 窗口 对 比 ， 推 断 出 用 户 正 在 如 何 更 改 窗口 的 大 小 ， 然 后 
计算 出 窗口 改变 后 的 几何 信息 ， 请 求 X 服 务 絮 改变 窗口 大 小 。 


当 鼠 标 释 放 时 ， 将 resizing_area 清 0 。 
EE 


7.1.11 切换 窗口 


我 们 以 图 7-12 所 示 的 场景 为 例 来 讨论 窗口 之 间 的 切换 。 应 用 A 和 应 用 B 
分 别 为 两 个 X 应 用 ， 图 中 使 用 虚线 标识 的 是 应 用 创建 的 窗口 ， 实 线 标 出 的 是 
窗口 管理 器 创建 的 窗口 。A1l 是 应 用 A 的 标准 类 型 的 顶层 窗口 ，A2 是 对 话 框 
类 型 的 顶层 窗口 ， 且 A2 是 窗口 A1 的 临时 窗口 。B1 有 是 应 用 B 的 标准 类 型 的 顶 
层 窗 口 ，B2 征 对 话 框 类 型 的 顶层 窗口 ， 且 B2 是 窗口 B1 的 临时 窗口 。 初 始 状 
态 X 时 ， 应 用 A 是 当前 活动 的 应 用 ; 在 状态 为 Y 时 ， 应 用 B 被 切换 为 当前 的 活 
动 应 用 。 


WinMan: active 


x cient B 二 于 


State X 


WinMan: active 


X Client A 


State Y 


图 7-12 切换 窗口 


当 将 应 用 B 切 换 为 当前 应 用 时 ， 窗 口 管理 器 需要 考虑 以 下 两 点 : 


多 窗口 管理 右 不 应 限制 用 户 只 有 点 击 在 窗口 管理 套 完 全 控制 的 闭 所 窗 
口上 才 可 以 切换 ， 即 使 电 标 指针 落 在 应 用 目 己 创建 的 窗口 上 ， 如 B1 窗 口 、 
B2 和 窗口 ， 窗 口 管理 硕 也 应 将 应 用 B 切 换 为 当前 活动 应 用 。 


令 窗口 管理 器 应 以 整个 应 用 为 单位 进行 切换 ， 即 将 应 用 B 的 所 有 窗口 都 
移动 到 X 服 务 器 窗口 栈 的 顶端 。 切换 完成 后 ， 窗 口 的 栈 序 应 该 为 


B2 一 Bl 一 A2 一 Al1， 而 不 是 类 似 如 B2 一 A2 一 Al>Bl。 


理解 了 上 面 两 点 后 ， 我 们 来 看 具体 的 切换 实现 ， 代 码 如 下 : 


winman/src/main.c: 


static void wm handle button press (WinMan *wm, XButtonEvent *e) 


GlLenkt “Gs 
Client *topmost,; 


if ((c = wm find client by frame (wm, e->window)) 
[|| (c = wm find client by window(wm, e->window))) { 
Le (To=strans. EGr) 4 
if (c != wm->active) 
C->activate(c) ; 
} else { 
topmost = transient get topmost (c) ; 
if (topmost != wm->active) 
c->activate (上 topmost) ; 


} 


函数 wm_handle_button_press 中 与 切换 相关 的 主要 操作 如 下 : 


1) winman 首 先 在 窗口 栈 中 寻找 鼠标 点 击 事件 发 生 的 窗口 对 象 。 
winman 既 考虑 了 妇 标 可 能 点 击 在 窗口 管理 器 创建 的 装饰 窗口 ， 也 考虑 了 女 
标 可 能 点 击 在 应 用 创建 的 窗口 的 情况 。 


2) 如 果 鼠 标点 击 的 窗口 不 是 临时 窗口 ， 并 且 也 不 是 当前 活动 的 窗口 ， 
则 调用 函数 指针 activate 指 向 的 函数 进行 切换 。 


3) 但 是 如 果 用 户 点 击 在 了 临时 窗口 上 ，winman 调 用 函数 
transient_get_topmost 一 直 找 到 非 临 时 窗口 ， 如 果 这 个 非 临 时 窗口 不 是 当前 
活动 的 窗口 ， 那 么 调用 画 数 指针 activate 指 回 的 函数 进行 切换 。 


以 标准 窗口 为 例 ， 画 数 指针 activate 指 向 函数 为 normal_client_activate， 
代码 如 下 : 


winman/src/normal client.c: 


static void normal client activate(Client *c) 
WinMan *wm = CcC->wm; 
Item *trans, *i; 


stack remove(c); 
stack append top(c); 


trans = normal client get _ transients(c) ; 
for (i = trans; i; i = i->next) { 
stack remove (i->client); 
stack append top(i->client); 
XUngrabButton (wm->dpy, Buttonl, 0, i->client->window); 


} 


list free(&trans); 
wm restack clients (wm); 


XUngrabButton (wm->dpy, Buttonl, 0, c->window); 
XAllowEvents (wm->dpy, ReplayPointer, CurrentTime),; 


if (wm->active) { 
XGrabButton (wm->dpy, Buttonl, 0, wm->active->window, 
True, ButtonpressMask, GrabModeSync, 
GrabModeSync, None, None); 


trans = normal client get transients (wm->active); 
for (i = trans; i; i = i->next) { 

XGrabButton(wm->dpy, Buttonl, 0, i->client->window, 
True, ButtonpressMask, GrabModeSync, 
GrabModeSync, None, None),; 

} 
list freel(g&trans); 


} 


wm->active = c; 
ewmh set net active window(wm->active); 


该 画 数 normal_client_activate 执 行 的 主要 操作 如 下 : 


1) 首先 要 调整 窗口 栈 序 ， 将 准备 激活 的 窗口 放 到 窗口 栈 的 最 项 


2) 如 果 窗 口 还 有 临时 窗口 ， 那 么 也 要 将 临时 窗口 移动 到 栈 的 最 顶 
因为 临时 窗口 可 能 还 有 临时 窗口 ， 这 就 是 代码 中 for 循 环 的 目的 。 


3) 安排 好 窗口 的 栈 序 后 ， 函 数 normal_client_activate 调 用 函数 
wm_restack_clients 请 求 X 服 务 絮 重新 调整 窗口 栈 序 。 函 数 wm_restack_clients 
就 是 将 winman 的 窗口 栈 中 的 窗口 按照 Xlib 的 函数 XRestackWindows 的 参数 格 
式 组 织 好 ， 然 后 调用 Xlib 的 函数 XRestackWindows 疝 XX 服务 器 发 出 调整 请 
求 。 从 这 里 我 们 再 次 深刻 地 体会 到 X 策 略 和 机 制 的 分 离 哲 学 : X 服 务 右 负责 
具体 的 切换 窗口 的 动作 ,但 是 ， 各 个 窗口 的 前 后 顺序 如 何 排 列 这 个 策略 由 

窗口 管理 需 来 负责 。 


4) 切换 窗口 后 ，winman 还 有 一 件 事 情 要 做 ， 那 就 是 取消 捕捉 刚刚 晋升 
的 活动 窗口 。 捕 提 的 目的 是 为 了 接收 非 当 前 活动 窗口 的 鼠标 事件 ， 而 对 于 


当前 活动 的 窗口 显然 没有 必要 继续 捕捉 了 。 而 且 如 果 不 取消 捕捉 窗口 的 刀 
标 事件 ， 那 么 每 次 点 击 窗口 时 ， 冉 标 事件 都 会 送 给 winman, 这 显然 是 没有 必 
要 的 ， 而 且 徒 增 X 服 务 器 和 窗口 管理 器 之 间 的 通信 量 。 


5) 接 下 来 ， 画 数 normal_client_activate 调 用 Xlib 的 函数 XAllowEvents 放 
行 捕捉 的 鼠标 事件 。 这 个 事件 就 像 一 个 接力 棱 一 样 ， 在 winman 中 去 留 了 一 
圈 ， 又 回 到 其 真正 属于 的 应 用 ， 不 至 于 造成 事件 丢失 。 但 是 前 提 是 捕捉 时 
必须 使 用 同步 模式 。 


6) 有 放 就 要 有 抓 ， 这 样 才能 张 凶 有 度 。winman 需 要 捕捉 上 一 个 活动 但 
是 马上 束 变 为 非 活 动 的 窗口 ， 包 括 其 临时 窗口 。 可 见 winman 不 仅 只 “ 见 新 人 
笑 ?”， 也 “ 国 旧 人 句 ”。 


7) 最 后 ，winman 更 新 了 根 窗口 的 属性 _NET_ACTIVE_WINDOW 。 
为 有 些 应 用 可 能 会 通过 根 窗口 的 这 个 属性 获取 当前 的 活动 窗口 ， 比 如 后 面 
的 窗口 组 件 任务 条 。 


7.1.12 ”最 大 化 /最 小 化 /关闭 窗口 


本 市 我 们 讨论 最 大 化 、 最 小 化 及 关闭 窗口 的 相关 知识 。 


1. 最 小 化 窗口 


最 小 化 窗口 本 质 上 就 古 取 消 窗 口 的 显示 ，Xlib 为 此 提供 了 相应 的 函数 


XUnmapWindow。 当 取消 某 个 窗口 的 显示 时 ， 同 时 也 需要 取消 其 临时 窗口 
的 显示 ， 代 码 如 下 : 


winman/src/normal _ client.c : 


static void minimize window(Client *c) 


WinMan *wm = C->wm; 
XUnmapWindow (wm->dpy, c->frame),; 


Item *trans = normal client get transients(c); 
Item *1i; 
£6 (LL, 定 tLaAnay IF TT 3 157Hext) 

XUnmapWindow (wm- >dpy, 


i->client->frame),; 
list freel(&trans); 


如 采取 消 了 一 个 窗口 的 显示 ， 那 么 如 何 再 恢复 它 的 显示 呢 ? 在 7.2 市 ， 
我 们 再 来 讨论 这 个 问题 。 


2. 最 大 化 /恢复 窗口 


所 谓 的 最 大 化 /恢复 窗口 ， 本 质 上 就 是 使 用 Xlib 的 类 似 如 
XMoveResizeWindow 的 函数 调整 窗口 位 置 和 大 小 ，winman 中 代码 中 对 应 的 


\[ 


实现 是 maximize_window 国 数 。 


唯一 需要 指出 的 就 是 ，winman 自 定义 了 属性 
_CUSTOM_WM_RESTORE_GEOMETRY， 在 最 大 化 之 前 将 窗口 的 几何 信 
息 ， 包 括 位 置 、 高 度 和 宽度 ， 都 记录 到 窗口 的 属性 中 。 为 什么 要 在 窗口 的 
属性 中 记录 ， 不 是 都 已 经 记录 到 窗口 对 象 中 了 吗 ? 试想 一 下 ， 如 果 不 在 窗 
口 的 属性 中 记录 ， 而 只 是 记录 在 窗口 管理 器 中 ， 一 旦 窗口 管理 器 异常 退 
出 ， 那 么 一 切 状 态 信 息 将 随 着 窗口 管理 器 灰 飞 烟 火 。 为 了 窗口 管理 器 再 次 
启动 时 能 获得 这 些 信息 ， 将 这 些 信息 保存 在 窗口 中 是 一 个 合理 的 办 法 。 


类 似 地 ， 在 最 大 化 /恢复 窗口 时 ，winman 也 更 新 了 窗口 的 另外 两 个 属性 
_NET_WM_STATF_MAXIMIZED_VERT 和 


_NET WM_ STATE MAXIMIZED HORZ。 
3. 天 闭 窗 口 


ICCCM 规 范 规定 ， 当 关闭 窗口 时 ， 窗 口 管理 器 应 该 发 送 消息 
WM_DELETE_WINDOW 给 应 用 ， 而 不 是 越 姐 代 让 地 请 求 X 服 务 器 去 销毁 应 
用 的 窗口 。 因 为 应 用 收 到 消息 WM_DELETE_WINDOW 后 ， 可 以 做 一 些 善 
后 处 理 ， 然 后 在 请 求 X 服 务 器 关闭 窗口 。 


当然 ， 有 些 应 用 程序 不 是 很 守 规矩 ， 尤 其 是 早期 使 用 Xlib 编 写 的 程序 ， 
它们 不 处 理 消息 WM_DELETE_WINDOW。 对 于 这 类 窗口 ， 也 只 能 采用 简 
单 粗暴 的 方法 了 ， 直 接 使 用 Xlib 提 供 的 函数 XKillClient 断 开 应 用 程序 到 又 服 
务 器 的 连接 ， 这 也 束 意 味 着 整个 X 应 用 彻底 退出 执行 。 


那么 窗口 管理 器 如 何 得 知 应 用 是 否 处 理 了 事件 
WM_DELETE_WINDOW? ICCCM 规 范 规 定 ， 如 果 窗 口上 自 己 负 责 销毁 ， 
应 该 在 窗口 的 属性 WM_PROTOCOLS 中 设置 属性 
WM_DELETE_WINDOW。 属 性 WM_PROTOCOLS 的 值 是 个 Atom 数 组 ， 其 
中 包括 多 个 属性 


我 们 来 看 一 下 winman 中 的 相关 代码 。 当 用 户 点 击 天 闭 按钮 时 ，winman 
将 调用 函数 icccm_delete_window， 代 码 如 下 : 


winman/src/ewmh icccm.c: 


void icccm delete window(Client *c) 
WinMan *wm = CcC->wm; 
Atom *protocols; 
int 4 nn Eoungd = 0 
XEvent ev; 


if (XGetWMProtocols (wm->dpy, c->window, &protocols, &n)) { 


for {二 0 1 Ty +) { 
if (protocols[i] == wm->atoms [WM DELETE WINDOW]) { 
found++; 
break; 


} 
} 


iE (PESGCOCOLS) 
XFree (protocols); 


} 


El ESG 1{ 
memset (&ev, 0, sizeof ev); 


ev.xclient.type = ClientMessage; 
ev.xclient.window = c->window; 
ev.xclient.message type = wm->atoms [WM PROTOCOLS]; 


ev.xclient.format = 32; 
ev.xclient.data.1[0] = wm->atoms [WM DELETE WINDOW]; 
ev.xclient.data.1[1] = CurrentTime; 


XSendEvent (wm->dpy, c->window, False, 0L, &ev); 
} else 
XKillClient (wm->dpy, c->window); 


函数 icccm_delete_window 检 查 窗口 的 属性 WM_PROTOCOLS， 若 其 中 
包含 属性 WM_DELETE_WINDOW， 那 么 就 发 消息 
WM_DELETE_ WINDOW 给 窗口 ， 否 则 调用 Xlib 的 函数 XKillClient 直 接 切 断 
应 用 和 X 服 务 硕 的 连接 。 


无 论 是 采用 哪 种 方式 ， 最 终 窗 口 一 定 会 离 我 们 而 去 的 。 虽 然 它 们 “ 轻 轻 
的 走 了 ， 不 带 走 一 片 云彩 *， 但 是 winman 还 是 要 做 一 些 必要 的 善后 处 理 的 ， 
最 起 码 ， 权 把 代表 窗口 的 对 象 释放 了 吧 。X 服 务 万 在 销毁 窗口 后 将 会 发 送 通 
知 UnmapNotify 给 窗口 管理 器 ，winman 在 这 个 事件 的 处 理 函 数 中 为 离 去 的 窗 
口 “ 销 户 ”。 以 标准 窗口 为 例 ， 其 对 应 的 “ 销 户 ”函数 如 下 : 


winman/src/normal client.c: 


static void normal client remove (ClLient *c) 


WinMan *wm = CcC->wm; 


stack remove(c); 


XReparentWindow (wm->dpy, c¢->window, wm->root, c->x, CcC->y); 


if(c->frame) 


XDestroyWindow (wm->dpy, c->frame); 


if (c == wm->active) { 
wm->active = stack get first nontransient (wm); 
if (wm->active) { 


XUngrabButton (wm->dpy, Buttonl, 0, wm->active->window); 


Item *trans = 


= normal client get transients (wm->active); 
Item *i; 
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XUngrabButton(c->wm->dpy, Buttonl, 0, 


i->client->window); 
list freel(&trans); 


ewmh set net active window(wm->active); 


ewmh update net client list stacking (wm); 


freel(c); 


函数 normal_client_remove 执 行 的 主要 操作 如 下 : 


1) 首先 从 窗口 栈 中 将 窗口 对 应 的 窗口 对 象 移 除 。 


2) 让 根 窗 口 收容 应 用 的 窗口 。 为 什么 要 做 这 么 一 件 事 呢 ? 因为 有 些 窗 
口 只 是 暂时 取消 显示 ， 比 如 我 们 经 常 进行 的 最 小 化 窗口 。 所 以 如 果 不 将 应 
用 的 窗口 从 Frame 窗 口 拆 除 ， 那 么 接 下 来 销 贤 Frame 时 ， 应 用 的 窗口 作为 
Frame 窗 口 的 子 窗 口 ， 也 将 一 并 被 销毁 。 


3) 安全 的 将 应 用 的 窗口 从 Frame 窗 口 脱离 后 ，normal_ client remove 调 
用 Xlib 的 芳 数 XDestroyWindow 销 毁 了 了 Frame 等 装饰 窗口 。 


4) 如 果 销 毁 的 窗口 是 当前 的 活动 窗口 ，winman 将 在 窗口 栈 中 试图 找到 
下 一 个 非 临 时 窗口 作为 当前 活动 的 窗口 。 如 有 果 找 到 了 ， 那 么 余下 要 做 的 承 
和 切换 窗口 类 似 了 。 


5) 当前 活动 窗口 变化 了 ， 窗 口 列表 也 变 了 。 函 数 normal_client_remove 
调用 相应 的 函数 更 新 根 窗口 的 属性 。 这 方面 的 内 容 前 面 已 多 次 见 过 ， 这 里 
就 不 再 讨论 了 。 


7.1.13 ”管理 已 存在 的 窗口 


在 窗口 管理 器 局 动 之 前 ， 可 能 有 一 些 应 用 已 经 在 运行 。 因 此 ， 在 窗口 
管理 絮 启 动 时 ， 需 要 管理 这 些 已 存在 的 窗口 。 这 就 是 winman 的 初始 化 时 调 
用 函数 init_clients 的 目的 。init_clients 的 实现 代码 如 下 : 


winman/src/main.c: 


static void init clients (WinMan *wm) 
Client *c; 
XWindowAttributes attr; 
Window root, parent, *children; 
unsigned int n, i; 


XQUeryTree (wm->dpy, wm->root, &root, &parent, &children, &n); 


for (i = 0; i < n; i++) { 
if (XGetWindowAttributes (wm->dpy, children[i], &attr)) { 
if (attr.override redirect == False 
&& attr.map state == IsViewable) { 
Cc = wm new client (wm, children [i]); 
dE (el) 


Cc->ignore unmap++; 


if (children) 
XFree (children),; 


函数 init_clients 执 行 的 主要 操作 如 下 : 


1) 调用 Xlib 的 画 数 XQueryTree 查 询 根 窗口 的 子 窗口 ， 参 数 children 指 癌 
保存 子 窗口 的 内 存 区 ， 变 量 n 记 杂 子 窗口 的 数量 。 


2) 遍历 根 窗口 的 子 窗口 ， 如 果 窗 口 的 属性 override_redirect 的 值 为 
False， 则 表明 窗口 需要 窗口 管理 大 管 理 ， 人 然后 检查 窗口 的 显示 状态 ， 如 果 


值 是 IsViewable， (IsViewable 表 示 的 意思 是 "Window is viewable"， 而 不 
是 "Is window viewable? ") ， 则 表示 窗口 是 可 见 的 ， 那 么 init_clients 就 调用 
函数 wm_new_dlient 开 始 管理 窗口 。 


3) 将 变量 ignore_unmap 累 加 1。 为 什么 需要 这 么 一 个 变量 ， 并 且 这 里 将 
其 累加 1 呢 ? 对 于 这 些 窗口 ， 在 窗口 管理 器 启动 前 ， 它 们 已 经 是 可 见 的 。 而 
为 了 管理 这 些 窗口 ， 窗 口 管理 器 将 使 用 Frame 窗 口 作为 它们 的 父 窗 口 ， 因 此 
它们 当然 要 首先 从 根 窗口 剥离 了 。 换 句 话 说 ，X 服 务 器 需要 将 窗口 从 窗口 树 
中 当前 的 位 置 删除 ， 并 插入 到 新 的 位 置 。X 当 然 不 想 让 人 看 到 它 的 这 个 小 动 
作 ， 因 此 ， 在 执行 这 个 过 程 前 ，X 服 务 器 首先 取消 这 些 窗口 的 显示 ， 也 就 是 
说 ，X 服 务 器 先 把 窗口 藏 起 来 ， 让 它们 不 可 见 ， 然 后 偷偷 摸 措 地 把 它们 移动 
到 窗口 树 中 新 的 位 置 ， 移 动 完成 后 ， 再 让 窗口 可 见 。 人 恰恰 是 X 服 务 器 的 这 个 
将 窗口 设置 为 不 可 见 的 动作 带 来 了 麻烦 。 在 X 服 务 器 取消 袜 口 的 可 见 状态 
时 ， 窗 口 管 理 器 将 收 到 通知 UnmapNotify， 如 果 不 加 任何 甄别 ， 将 导致 
init_clients 刚 刚 管 理 的 窗口 又 被 销 贤 。 显 然 ， 这 不 是 我 们 希望 的 ， 因 此 结构 
体 Client 中 设计 了 变量 ignore_unmap 来 忽略 这 个 特殊 的 UnmapNotify 事 件 。 


至 此 ， 我 们 的 迷你 窗口 管理 管理 器 开发 完成 了 ， 我 们 将 其 复制 到 vita 系 
统 ， 并 使 用 如 下 命令 运 


root@vita:~# Xorg -retro -noreset & 
root@vita:~# export DISPLAY=:0.0 
root@vita:~# ./winman & 
root@vita:~# ./hello gtk & 


如 琳 没 有 问题 ， 将 看 到 一 个 类 似 图 7-13 所 示 的 窗口 。 


Hello GTK! 


) 人 各国 谤 | 从 加 右 ctrl 


图 7-13 窗口 管理 器 


根据 图 7-13 中 可 见 ，hello_gtk 的 窗口 不 再 是 一 个 光秃秃 的 裸 窗口 了 ， 它 
被 添加 了 各 种 装饰 ， 看 上 去 更 有 立体 感 了 。 而 且 我 们 可 以 拖 住 标题 栏 移动 
窗口 ， 也 可 以 改变 窗口 大 小 ， 可 以 关闭 窗口 ， 可 以 最 大 化 窗口 ， 但 是 一 旦 
最 小 化 窗口 ， 束 再 也 找 不 到 它 了 。 下 一 节 ， 我 们 构建 了 任务 条 来 解决 这 个 


问题 


7.2 ”任务 条 和 先 面 


从 最 初出 现在 梨 面 环境 中 发 展 到 现在 ， 任 务 条 的 风格 也 在 不 断 地 发 生 
改变 ， 但 依然 是 梨 面 环境 的 重要 组 件 之 一 ， 只 不 过 表现 形式 并 不 一 定 是 于 
篇 一 律 。 


EI 


典型 的 任务 条 从 左 至 右 包 括 “ 开 始 按 钮 "、“ 快 速 局 动 福 *”、“ 任 务 项 ”以 
及 “通知 区 域 "。 用 户 通 过 “开始 按钮 "可 以 启动 应 用 程序 ;“ 快 速 启动 栏 ”中 放 
置 用 户 第 用 的 一 些 程 序 ， 每 个 局 动 的 任务 都 有 一 个 “任务 项 ”; “通知 区 域 " 主 
要 用 来 显示 一 些 系统 状态 ， 比 如 显示 当前 的 输入 法 、 网 络 状 态 


除了 任务 条 外 ， 一 般 的 桌面 环境 都 有 一 个 育 景 ， 并 且 在 这 个 育 景 上 面 
可 以 显示 一 些 快 捷 方 式 ， 可 以 显示 一 些 很 有 个 性 的 小 插件 。 


本 章 中 ， 我 们 实现 了 一 个 简单 的 任务 条 和 一 个 桌面 。 不 同 的 桌面 环 
境 ， 实 现 这 些 组 件 的 逻辑 不 尽 相 同 ， 有 的 是 放 在 一 个 完整 的 程序 中 ， 有 的 
是 每 个 组 件 是 一 个 单独 的 程序 ， 我 们 采用 后 者 。 我 们 通过 这 两 个 程序 向 读 
者 展示 使 用 图 形 库 (GTK) 编程 。 相 比 于 Xlib，GTK 的 编程 理解 起 来 要 容 
易 得 多 ， 而 且 GTK 的 官方 文档 写 得 也 非常 详尽 ， 所 以 我 们 就 不 浪费 篇 幅 讨 
论 有 关 GTK 的 编程 了 ， 这 里 仅 讨论 其 中 与 窗口 管理 器 相关 的 部 分 


7.2.1 标识 任务 条 的 身份 


虽然 任务 条 也 是 一 个 普通 X 应 用 ， 但 是 作为 桌面 环境 中 重要 的 一 个 组 
件 ， 还 是 有 一 些 特殊 的 地 方 。 比 如 ， 在 我 们 构建 的 桌面 环境 中 ， 窗 口 管理 
器 将 其 停靠 在 屏幕 的 最 下 方 。 但 是 任务 条 如 何 向 winman 亮 明 自 己 的 任务 吴 
份 呢 ? 读者 一 定 已 经 猜 到 了 : 属性 。 任 务 条 自 定义 了 属性 
_CUSTOM_WM_WINDOW_TYPE_TASKBAR， 在 启动 时 ， 其 将 窗口 的 属 


性 NET WM_WINDOW_TYPE 设 置 为 属性 
_CUSTOM_WM_WINDOW_TYPE_TASKBAR， 如 下 代码 所 示 : 


taskbar/src/main.c: 


int mainl(int argc, char *argv[]) 


{ 


XChangeProperty (taskbar->dpy, wid, 
taskbar->atoms[_ NET WM WINDOW TYPE], 
XA ATOM, 32, PropModeReplace, (unsigned char *) 
&taskbar->atoms[_ CUSTOM WM WINDOW TYPE TASKBAR], 1); 


winman 一 旦 发 现 窗口 的 类 型 为 
_CUSTOM_WM_WINDOW_TYPE TASKBAR， 则 将 其 作为 任务 条 管理 ， 
让 我 们 回顾 一 下 winman 中 给 “窗口 ”落户 的 相关 代码 : 


winman/src/main.c: 


static Client* wm new client (WinMan *wm, Window win) 


{ 


status = XGetWindowProperty (wm->dpy, win, 
wm->atoms[ NET WM WINDOW TYPE], 
0, 1, False, XA ATOM, &type, &format, &n, 
&extra, (unsigned char **)&value); 
else if (value [0] == 
wm- >atoms [_CUSTOM WM WINDOW TYPE TASKBAR]) 
C = taskbar client newl(wm, win); 


如 果 winman 发 现 窗口 的 类 型 是 
_CUSTOM_ WM_ WINDOW_TYPE_TASKBAR，winman 将 不 再 创建 标准 窗 
口 的 对 象 ， 而 是 创建 一 个 任务 条 窗口 对 象 ， 代 码 如 下 : 


winman/src/taskbar client.c: 


Client* taskbar client new(WinMan *wm, Window win) 
{ 
Es 
c->y = DisplayHeight (wm->dpy, wm->screen) - TASKBAR HEIGHT; 


c->width = DisplayWidth(wm->dpy, wm->screen); 
c->height = TASKBAR HEIGHT; 


XMoveResizeWindow (wm->dpy, win, c->x, Cc->y, Cc->width, 
C->height) ; 


Cc->reparent = &taskbar client reparent; 


其 中 比较 有 趣 的 两 个 地 方 ， 我 们 需要 特别 关注 : 


1) winman 将 任务 条 布局 在 特定 的 位 置 。 其 左 起 屏幕 最 左边 ， 宽 度 为 整 
个 屏幕 。 高 度 为 TASKBAR_HEIGHT， 这 个 宏 在 winman 中 定义 ， 值 为 30 像 


素 。 位 于 屏幕 的 底部 。 
2) 任务 条 的 构建 窗口 装饰 的 函数 taskbar_client_reparent， 其 实现 如 下 : 


winman/src/taskbar client.c: 


static void taskbar client reparent (Client *c) 


{ 
} 


函数 体 怎么 是 空 的 ? 没 错 ， 任 务 条 不 需要 任何 装饰 。 读 者 可 能 会 问 ， 
那 为 什么 定义 这 么 一 个 空 图 数 体 ? 这 个 主要 征 出 于 面 癌 对 象 实现 上 的 考 
虑 ， 当 然 ， 条 条 大 路 通 罗 马 ， 聪 明 的 读者 也 可 以 不 需要 定义 这 么 个 空 函 
数 ， 而 十 采用 调用 前 判断 钞 数 指针 是 否 为 空 ， 等 等 。 


7.2.2 更新 任务 条 上 的 任务 项 


前 面 我 们 看 到 ， 在 winman 中 ， 每 当 为 一 个 窗口 “落户 ?时 ，winman 都 将 
更 新 根 窗 口 的 属性 NET_CLIENT_LIST_STACKING。 因 此 ， 任 务 条 利用 的 


束 古 这 个 机 制 ， 监 测 根 窗口 属性 的 变化 ， 从 而 跟踪 系统 中 任务 的 变化 ， 相 
天 代码 如 下 : 


taskbar/src/main.c: 


int main(int argc, char *argv[]) 


{ 


gdk window set events (root, GDK PROPERTY CHANGE MASK); 
gdk window add filter(root, root window event filter, taskbar).,; 


static GdkFilterReturn root window event filter (GdkXEvent 
*xevent, GdkEvent *event, gpointer data) 


XPropertyEvent *prop; 
Taskbar *taskbar = data; 


prop = (XPropertyEvent*)xevent,; 
} else if (prop->atom == 
taskbar->atoms{[_ NET CLIENT LIST STACKING]) { 


taskbar setup items (taskbar); 
} else if (prop->atom == taskbar->atoms[ NET SHOWING DESKTOP]) 


在 任务 条 初始 化 时 ， 其 将 选择 根 窗口 事件 掩 码 PropertyChangeMask， 并 
设置 根 窒 口 的 属性 变化 事件 的 回调 函数 为 root_ window_event_ filter。 如 此 ， 
一 旦 根 窗口 的 属性 发 生变 化 时 ， 任 务 条 都 将 洞悉 。 


每 当 根 窗 口 的 属性 NET_CLIENT_LIST_STACKING 发 生变 化 时 ， 画 数 
taskbar_setup_items 就 读 取 根 窗口 的 该 属性 的 值 ， 获 取 目 前 系统 中 全 部 的 窗 
口 列 表 。 然 后 遍历 这 个 列表 ， 更 新 任务 栏 。 为 了 简单 ， 该 函数 做 了 很 多 简 
化 ， 比 如 只 要 窗口 类 型 是 NET_WM_WINDOW_TYPE_NORMAL， 并 且 也 
没有 判断 窗口 是 否 是 其 他 窗口 的 临时 窗口 ， 任 务 条 束 为 其 在 任务 条 上 创建 
一 个 任务 项 。 


作为 吕 面 环境 的 核心 组 件 之 一 ， 在 加 面 环境 启动 时 ， 任 务 条 十 首先 局 
动 的 核心 组 件 之 一 。 理 论 上 ， 这 个 时 候 还 没有 应 用 启动 ， 但 是 不 排除 系统 
运行 过 程 中 ， 任 务 条 重新 局 动 ， 谁 也 不 能 保证 程序 完全 没有 bug。 因此 ,天 
论 如 何 ， 任 务 条 还 是 有 必要 在 局 动 时 获取 系统 中 正在 运行 的 任务 ， 并 为 它 
们 在 任务 条 上 建立 相应 的 任务 项 。 这 个 过 程 请 读者 参考 随 书 光盘 中 附带 的 
源 代码 。 
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激活 任务 


任务 条 的 另外 一 个 主要 任务 束 是 将 最 小 化 的 ， 或 者 将 非 活动 的 窗口 激 


活 为 当前 活动 窗口 。 


EWMH 规 范 规定 ， 如 果 一 个 X 应 用 希望 激活 男 外 一 个 窗口 ， 可 以 通过 
向 根 窗口 发 送 消息 NET_ACTIVE_WINDOW 来 实现 。 因 此 ， 在 我 们 的 任务 
条 中 ， 当 用 户 点 击 任务 按钮 时 ， 在 回调 函数 中 将 向 根 窗口 发 送 
ClientMessage 事 件 ， 其 中 的 消息 类 型 为 NET_ACTIVE_WINDOW， 代 码 如 


下 : 


taskbar/src/taskbar item.c: 


static void taskbar item clicked cb (TaskbarItem *item, ...) 


{ 
} 


ewmh send net active window (item); 


taskbar/src/ewmh.c: 


void ewmh send net active window(TaskbarItem *item) 


{ 


XEvent e; 


memset (&e, 0, sizeof (e)); 

e.xclient.type = ClientMessage; 

e.xclient .window = item->win; 

e.xclient .message type = 
item->taskbar->atoms[ NET ACTIVE WINDOW]; 
e.xclient.format = 32; 


XSendEvent (item->taskbar->dpy, GDK ROOT WINDOW(), False, 
SubstructureNotifyMask | SubstructureRedirectMask, &e); 


事实 上 ， 任 务 条 发 给 根 窗口 ClientMessage 事 件 也 被 窗口 管理 絮 拦 截 
了 。 读 者 可 能 有 个 疑问 ， 窗口 管理 器 会 收 到 应 用 发 给 根 窗口 的 类 型 为 
ClientMessage 的 事件 吗 ? 管 案 是 肯定 的 。 因 为 EWMH 规 定 ，ClientMessage 


对 应 的 事件 措 码 是 SubstructureNotifyMask 和 SubstructureRedirectMask， 而 窗 


口 管理 器 恰恰 选择 了 接收 SubstructureNotify 和 SubstructureRedirect 。 


winman 中 处 理事 件 ClientMessage 的 代码 如 下 : 


winman/src/main.c: 


static void wm handle client message (WinMan *wm, 
XClientMessageEvent *e) 


} else if (e->message type == wm->atoms{[ NET ACTIVE WINDOW]) { 
if (c = wm find client by window(wm, e->window)) { 
C->Show(c) ; 
C->activate(c) ; 


函数 wm_handle_client_message 检 查 消 息 的 类 型 ， 如 果 是 
_NET_ACTIVE_WINDOW， 则 调用 窗口 对 象 中 范 数 指针 activate 指 疝 的 函 
数 ， 将 事件 XClientMessageEvent 中 指定 的 窗口 切换 为 当前 活动 窗口 。 具 体 
的 过 程 我 们 在 7.1.11 一 节 已 经 详细 讨论 了 。 


在 调用 activate 前 ， 琴 数 wm_handle_client_message 还 调用 了 加 数 show 。 
目的 是 什么 呢 ? 原因 是 窗口 可 能 上 次 被 最 小 化 了 ， 因 此 首先 需要 请 求 X 服 务 


如 显示 这 个 窗口 。 


7.2.4 局 完 显示 当前 活动 任务 


当 某 个 任务 成 为 当前 活动 任务 时 ， 任 务 条 需要 将 对 应 的 任务 项 特殊 标 
一 下 。 那 么 任务 条 如 何 知道 当前 任务 已 经 发 生变 化 了 呢 ? 前 面 我 们 看 
到 ， 在 winman 中 ， 每 当 为 将 一 个 窗口 设置 为 当前 活动 窗口 时 ，winman 都 将 
更 新 根 窗 口 的 属性 NET_ACTIVE_WINDOW 。 看 到 这 里 ， 读 者 一 定 明白 

了 ， 任 务 条 的 处 理 过 程 与 7.2.2 节 基本 完全 相同 ， 相 关 代码 如 下 : 


taskbar/src/main.c: 


static GdkFilterReturn root window event filter( 
GdkXEvent *xevent, GdkEvent *event, gpointer data) 


XPropertyEvent *prop; 
Taskbar *taskbar = data; 


prop = (XPropertyEvent*)xevent; 


if (prop->atom == taskbar->atoms[_ NET ACTIVE WINDOW]) { 
Window active win = ewmh get net active window (taskbar) ; 


函数 root_window_event_filter 用 于 检查 根 窗口 发 生变 化 的 属性 的 值 ， 如 
果 是 _ NET_ACTIVE_WINDOW， 说 明 当 前 活动 的 窗口 改变 了 ， 任 务 条 从 根 
窗口 读 取 当 前 活动 的 窗口 ， 然 后 将 其 在 任务 条 上 对 应 的 项 高 亮 显示 。 


7.2.5 ”显示 桌面 


当 用 户 按 下 快速 局 动 栏 上 的 显示 桌面 按钮 和 时， 将 把 介面 显示 到 所 有 和 窗 


口 的 最 前 面 。 本 章 讨论 到 这 里 ， 我 想 读者 应 该 已 经 大 致 可 以 猜 出 这 个 故事 


的 脚本 了 : 


1) 任务 条 向 根 窗口 发 送 类 型 为 ClientMessage 的 事件 ，EWMH 规 范 规定 
这 个 事件 中 的 消息 类 型 为 NET_SHOWING DESKTOP。 


2) winman 请 求 X 服 务 器 将 将 桌面 这 个 组 件 显示 到 窗口 栈 的 最 上 面 。 
winman 中 的 实现 与 切换 窗口 基本 完全 相同 。 


下 


下 面 束 是 任务 条 中 当 用 户 点 击 显示 桌面 按钮 后 发 送 消 轧 的 相关 代码 : 


Taskbar/src/ewmh.c: 


void ewmh send net showing destkop (Taskbar *taskbar) 


{ 


XEvent e; 


memset (&e, 


e.xclient 
e.xclient 


e.xclient. 
.data.1[0] = 1; 


e.xclient 


0, sizeof (e)); 


.type = ClientMessage,; 
.message type = 


taskbar->atoms[ NET SHOWING DESKTOP]; 
format' 去 327 


XSendEvent (taskbar->dpy, GDK ROOT WINDOW(), False, 


SubstructureNotifyMask | SubstructureRedirectMask, 


&e); 


7.2.6 ”桌面 


相 比 于 任务 条 ， 这 个 示例 的 桌面 程序 要 简单 很 多 。 而 且 ， 经 过 了 前 面 
任务 条 的 讨论 ， 我 想 读 者 应 该 不 需要 笔者 再 过 多 的 哆 唆 了 。 同 普通 应 用 对 
比 ， 其 比较 特殊 的 地 方 之 一 束 古 ， 要 问 窗 口 管 理 絮 腕 明 目 己 的 映 份 ， 代 码 
如 下 所 示 : 


desktop/src/main.c: 


二 世相 mim(inb Srge,. CHar Wrav [0]} 


{ 


gtk window set type hint (GTK WINDOW (win), 
GDK WINDOW TYPE HINT DESKTOP); 


桌面 程序 使 用 标准 的 EWMH 规 范 规定 的 属性 
_NET_WM_WINDOW_TYPE_DESKTOP 标 识 该 程序 是 一 个 桌面 程序 。GTK 
中 的 函数 gtk_window_set_type_hint 束 是 对 Xlib 的 函数 XChangeProperty 的 更 
高 层 的 封装 ， 我 们 直接 使 用 即 可 。 


winman 将 为 桌面 程序 创建 桌面 窗口 对 象 ， 并 将 其 整个 铺 满 在 桌面 背景 
上 。 同 样 ， 昌 面 窗口 对 象 也 不 需要 竣 炳 ， 因 此 其 函数 desktop_client_reparent 
也 是 个 空 画 数 。 其 他 细节 ， 请 读者 参考 随 书 光 副 中 附带 的 源 代码 。 


至 此 ， 一 个 基本 的 揭 面 环境 吏 已 经 搭建 完毕 了 ， 读 者 将 它们 安 痛 到 vita 
系统 ， 然 后 使 用 如 下 命令 即 可 局 动 完整 的 梨 面 环境 


root@vita:~# Xorg -retro -noreset & 
root@vita:~# export DISPLAY=:0.0 
root@vita:~# ./winman & 
root@vita:~# ./desktop & 
root@vita:~# ./taskbar & 


注意 ， 桌 面 程序 上 的 快捷 方式 "Hello World" 的 回调 函数 将 到 目录 /usr/bin 
下 寻找 程序 hello_gtk， 所 以 请 将 这 个 程序 复制 到 目录 /usr/bin 下。 另外， 也 请 
确保 程序 taskbar、desktop 使 用 的 css 主 题 描述 安装 在 正确 的 目录 下 。 如 采 明 
到 厅 烦 ， 请 读者 参考 随 书 光 弄 中 附带 的 源 代码 。 


如 琳 一 切 正常 ， 将 看 到 一 个 类 似 图 7-14 所 示 的 完整 倘 面 环境 


11.10 [正在 运行 ] - Oracle VM VirtualBox 


Hello GTK! 


图 日 上 9 旬 自 天 | 者 轩 友 ctrl 
图 7-14 完整 的 桌面 环境 


这 是 一 个 经 典 的 PC 上 的 桌面 环境 。 桌 面 下 方 是 个 任务 条 ， 其 最 左 侧 是 
个 “开始 "按钮 。 然 后 紧 接着 是 快速 启动 栏 ， 其 中 包含 一 个 “显示 桌面 的 按 
钮 。 接 下 来 当然 就 是 各 个 任务 项 了 。 在 图 7-14 所 示 的 例子 中 ， 我 们 运行 了 两 
个 hello_gtk 程 序 ， 所 以 在 任务 条 上 有 两 个 任务 项 。 同 时 有 一 个 程序 专门 负责 
桌面 的 背景 ， 当 然 其 上 面 还 可 以 添加 各 种 程序 的 快捷 方式 ， 比 如 这 里 添加 
了 程序 hello_gtk 的 快捷 方式 。 


什么 ? 没有 Dashboard (Mac OS X 的 很 有 特色 的 一 个 桌面 组 件 ) ? 是 
的 ， 这 是 一 个 很 简陋 的 蝎 面 环境 。 但 是 通过 这 个 季 陋 的 时 面 ， 我 们 已 经 
楚 了 桌面 环境 的 基本 组 成 及 运行 原理 ， 接 下 来 ， 你 可 以 按照 意愿 随意 改 

， 甚 至 可 以 沭 加 一 个 新 的 揭 面 组 件 ， 但 是 记得 告诉 窗口 管理 居 将 其 放 在 
了 哪 一 个 特殊 的 位 置 。 


虽然 如 今 的 梨 面 环境 越 来 越 个 性 化 ， 束 如 同 那个 “开始 ”按钮 都 可 能 请 
失 一 样 ， 但 是 事实 上 ， 这 些 都 是 表面 现象 。 如 果 你 对 众多 操作 系统 比较 了 
解 ， 你 束 会 知道 ， 它 们 本 质 上 完全 相同 ， 只 是 表象 不 同 而 已 ， 束 看 你 古 否 
足够 艺 高 且 敢 于 创造 了 。 


第 8 草 ”Linux 图 形 原 理 探 讨 


在 第 6 革 和 第 7 章 中 ， 我 们 揭示 了 在 Linux 操 作 系 统 中 ， 图 形 系统 
桌面 环境 的 构成 。 这 一 草 ， 我 们 进一步 深入 ， 壬 试探 讨 Linux 的 图 形 原 
理 。 


本 质 上 ， 谈 及 图 形 原理 必 会 涉及 泻 染 和 显示 两 部 分 。 但 是 显示 过 
程 比较 简单 和 直接 ， 而 渲染 过 程 要 复杂 得 多 ， 更 重要 的 是 ， 洽 染 率 扯 
到 操作 系统 内 部 的 组 件 更 多 ， 因 此 ， 本 章 我 们 主要 讨论 渲染 过 程 。 我 
们 不 想 只 浮 于 理论 ， 结 合 具 体 的 GPU 进 行 讨论 更 有 助 于 深度 理解 计算 
机 的 图 形 原理 。 相 比 于 NV 及 ATI 的 GPU， 我 们 选择 相对 更 开放 一 些 的 
Itel 的 GPU 进行 讨论 。Itel 的 GPU 也 在 不 断 的 演进 ， 本 书写 作 时 主要 针 
对 的 是 用 在 Sandy Bridge 和 Ivy Bridge 架 构 上 的 Intel HD Graphics。 


显存 是 图 形 演 染 的 基础 ， 也 是 理解 图 形 原理 的 基础 ， 因 此 ， 本 章 
我 们 从 讨论 显存 开始 。 或 许 读者 会 说 ， 显 存 有 什么 好 讨论 的 ， 不 就 是 
一 块 存储 区 吗 ? 早已 是 陈 词 洲 调 。 但 是 事实 并 非 如 此 ， 通 过 显存 的 讨 
论 ， 我 们 会 注意 到 CPU 和 GPU 融合 的 脚步 ， 会 看 到 它们 是 如 何 的 和 谐 
共享 物理 内 存 的 。 或 许 ， 已 经 有 GPU 和 CPU 完美 地 进行 统一 寻 址 了 。 


然后 ， 我 们 分 别 讨论 2D 和 3D 的 泻 染 过 程 。 在 其 则 ， 我 们 将 看 到 到 
帮 何 请 人 硬件 加 速 ， 我 们 也 会 从 更 深 的 层次 去 展示 3D 泻 染 过 程 中 所 请 的 


Pipeline。 以 往 ， 很 多 教材 都 会 为 了 辅助 OpenGL 的 应 用 开发 ， 多 少 从 理 
论 上 谈 及 一 点 Pipeline， 而 在 这 一 章 中 ， 我 们 从 操作 系统 角度 和 Pipeline 
进行 一 次 亲密 接触 。 


最 后 ， 我 们 讨论 了 很 多 读者 认为 神秘 而 阳 生 的 Wayland。 其 实 ， 
Wayland 既 不 神秘 也 不 卫生 ， 它 是 在 DRI 和 复合 扩展 发 展 的 背景 下 产生 
的 ， 基 于 DRI 和 复合 扩展 演进 的 成 果 。 从 某 个 角度 ，Wayland 更 像 是 去 
除了 基于 网 络 的 服务 郁 / 客 户 端的 X 和 复合 管理 融 的 一 次 整合 。 


8.1 洽 染 和 显示 


计算 机 将 图 形 显 示 到 显示 设备 上 的 过 程 ， 可 以 划分 为 两 个 阶段 : 
第 一 阶段 是 泻 染 (render) 过 程 ， 第 二 阶段 是 显示 (display) 过 程 ， 如 
图 8-1 所 示 。 
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图 8-1 图 形 渲染 显示 过 程 示意 图 


所 谓 泻 染 就 是 将 使 用 数学 模型 描述 的 图 形 ， 
如 "DrawRectangle(x1,y1,x2,y2)"， 转 化 为 像素 阵列 ， 或 者 叫 像素 数组 。 
像素 数组 中 的 每 个 元 素 是 一 个 颜色 值 或 者 颜色 索引 ， 对 应 图 像 的 一 个 
像素 。 对 于 X 窗 口 系统 ， 数 组 中 的 元 素 是 一 个 颜色 索引 ， 具 体 的 颜色 根 
据 这 个 索引 从 颜色 映射 (Colormap) 中 查询 得 来 。 


演 染 通常 又 被 分 为 两 种 ， 一 种 渲染 过 程 是 由 CPU 完 成 的 ， 通 第 称 
为 软件 洽 染 ， 男 外 一 种 是 由 GPU 完 成 的 ， 通 常 称 为 硬件 痊 染 ， 也 束 是 
我 们 肖 第 提 到 的 硬件 加 速 。 


谈 及 泻 染 ， 不 得 不 提 的 另外 一 个 关键 概念 束 是 帧 绥 冲 
(Framebuffer) 。 从 字面 意义 上 讲 ，frame 表 示 屏 幕 上 的 某 个 时 刻 对 应 
的 一 帆 独 像 ，buffer 丈 是 一 段 存 储 区 了 ， 因 此 ， 在 狭义 上 ， 合 起 来 的 这 
个 词 就 是 指 存储 一 帧 屏幕 图 像 像素 数据 的 存储 区 。 


但 是 从 广义 上 ， 帧 缓冲 则 是 多 个 缓 促 区 的 统称 。 比 如 在 OpenGL 
中 ， 帧 缓冲 包括 用 于 输出 的 颜色 缓冲 (Color Buffer) ， 以 及 辅助 用 来 
创建 颜色 缓冲 的 深度 缓冲 (Depth Buffer) 和 模板 缓冲 (Stencil 
Buffer) 等 。 即 使 在 2D 环 境 中 ， 帧 缓冲 这 个 概念 也 不 仅 指 屏幕 上 的 一 帧 
图 像 ， 还 包含 用 于 存储 命令 的 缓冲 (Command Buffer) 等 。 每 一 个 应 
用 都 有 目 己 的 一 套 帧 缓冲 。 


在 OpenGL 环 境 中 ， 为 了 避免 渲染 和 显示 过 程 交 义 导 致 冲 突 ， 从 而 
出 现 如 撕 裂 (tearing) 以 及 闪烁 (flicker) 等 现象 ， 颜 色 缓 冲 又 被 划分 
为 前 缓冲 (front buffer) 和 后 缓冲 (back buffer) 。 如 果 为 了 文 持 立体 
效果 ， 则 前 缓冲 和 后 缓冲 又 分 别 划 分 为 左 和 右 各 两 个 缓冲 区 ， 我 们 不 
讨论 这 种 情况 。 前 缓冲 和 后 缓冲 中 的 内 容 都 是 像素 阵列 ， 每 个 像 隶 或 
者 是 一 个 颜色 值 ， 或 者 是 一 个 颜色 索引 。 只 不 过 前 缓冲 用 于 显示 ， 后 
绥 冲 用 于 泻 染 。 

2D 可 以 看 作 3D 的 一 个 特例 ， 因 此 ， 我 们 将 2D 程 序 中 用 于 输出 的 组 
冲 区 称 为 前 缓冲 。 为 了 避免 蚊 义 ， 在 容易 引起 混 消 的 地 方 我 们 尽量 不 
使 用 这 个 多 义 的 帧 缓冲 一 词 。 


8.1.2 ”显示 


一 般 而 言 ， 显 示 设 备 也 使 用 像素 来 衡量 ， 比 如 屏幕 的 分 辨 率 为 
1366x768， 那 么 其 可 以 显示 1049 088 个 像素 ， 一 个 像素 对 应 屏幕 上 的 
一 个 点 ， 图 像 就 是 通过 这 些 点 显示 出 来 的 。 通 常 ， 图 像 中 一 个 像素 对 
应 屏幕 上 的 一 个 像素 ， 那 么 将 图 像 显 示 到 屏幕 的 过 程 就 是 逐个 读 取 帧 
缓冲 中 存储 的 图 像 的 像素 ， 根 据 其 所 代表 的 颜色 值 ， 控 制 显示 侣 上 对 
应 的 点 显示 相应 颜色 的 过 程 。 


通常 ， 显 示 过 程 基 本 上 要 经 过 如 下 几 个 组 件 ， 显示 控制 需 
(CRTC) 、 编 码 器 (Encoder) 、 发 射 器 (Transmitter) 、 连 接 器 


(Connector) ， 最 后 显示 在 显示 器 上 。 


(1) 显示 控制 器 


显示 控制 大 负 责 读 取 帧 缓冲 中 的 数据 。 对 于 X 来 说 ， 由 缓冲 中 存 
储 的 是 颜色 的 索引 ， 显 示 控 制 厦 读 取 索 引 值 后 ， 还 需要 根据 索引 值 从 
颜色 映射 中 查询 具体 的 闫 色 值 。 显 示 控 制 紫 也 仙 贡 产生 同步 信号 ， 典 
型 的 如 水 平 同 步 信 号 (HSYNC) 和 垂直 同步 信号 (VSYNC) 。 水 平 
同步 信号 目的 是 通知 显示 设备 开始 显示 新 的 一 行 ， 垂 直 同 步 信 与 通知 
显示 设备 开始 显示 新 的 一 巾 。 所 谓 同步 ， 以 垂直 同步 信和 与 为 例 ， 我 们 
可 以 这 样 来 通俗 地 理解 它 ， 显 示 控 制 右 开始 扫 揪 新 的 一 帧 数据 了 ， 因 


通过 这 个 信号 告诉 显示 更 开 始 显 示 ， 跟 上 我 ， 不 要 掉队 ， 这 束 古 
意思 。 以 CRT 显 示 天 为 例 ， 这 两 个 信号 控制 者 电子 枪 的 移动 ， 
每 显示 完 一 行 ， 电 子 枪 痢 会 回溯 到 下 一 行 的 开始 ， 等 得 下 一 个 水 平 同 
言 号 的 到 来 。 每 显示 完 一 帧 ， 电 子 枪 都 会 回溯 到 屏幕 的 左上 角 ， 

一 下 垂直 同步 信号 的 到 来 。 


村 由 


下 


(2) 编码 器 


对 于 帧 绥 冲 中 每 个 像素 ， 可 能 使 用 8 位 、16 位 、32 位 甚至 更 多 的 位 
来 表示 颜色 值 ， 但 是 对 于 具体 的 接口 来 说 ， 却 远 没 有 这 么 多 的 数据 线 
供 使 用 ， 而 且 不 同 的 接口 有 不 同 的 格式 规定 。 比 如 对 于 VGA 接 口 来 
说 ， 总 共 只 有 三 根 数据 线 ， 每 个 颜色 通道 占用 一 根 数据 线 ;， 对 于 LVDS 
来 说 ， 数 据 征 串 行 传输 的 。 因 此 ， 需 要 将 CRTC 读 取 的 数据 编码 为 适 
合 具体 物理 接口 的 编码 格式 ， 这 融 是 编码 套 的 作用 。 


(3) 发 射 器 


发 射 右 将 经 过 编码 的 数据 转变 为 物理 信号 。 读 者 可 以 将 其 想象 
成 : 发 射 器 将 1 转化 为 高 电 平 ， 将 0 转化 为 低 电 平 。 当 然 ， 这 只 是 一 个 
形象 的 说 法 。 


(4) 连接 器 


连接 器 有 时 也 被 称 为 端口 (Port) ， 比 如 VGA、LVDS 等 。 它 们 直 
接连 接着 显示 设备 ， 负 责 将 发 射 器 发 出 的 信号 传递 给 显示 设备 。 


Intel 的 GPU 集 成 到 心 片 组 中 ， 一 般 没有 专用 显存 ， 通 常 是 由 BIOS 从 系 
统 物理 内 存 中 分 配 一 块 空间 给 GPU 作 专用 显存 。 一 般 而 言 ，BIOS 会 有 个 默 
认 的 分 配 规则 ， 有 的 BIOS 也 会 为 用 户 留 有 接口 ， 用 户 可 以 通过 BIOS 设 置 显 
存 的 大 小 。 如 对 于 具有 1GB 物 理 内 存 的 系统 来 说 ， 可 以 划分 256MB 内 存 给 
GPU 用 作 显 存 。 


但 是 这 种 静态 的 分 配方 式 带 来 的 问题 之 一 束 古 如 何平 衡 系统 与 显示 占 
用 的 内 存 ， 究 竟 分 配 多 少 内 存 给 GPU 才 能 在 系统 常规 使 用 和 运行 图 形 计 算 
密集 的 应 用 (如 3D 应 用 ) 之 间 达 到 最 优 。 如 果 分 配给 GPU 的 显存 少 了 ， 那 
么 在 进行 图 形 处 理 时 性 能 必然 会 降低 。 而 单纯 提高 分 配给 GPU 的 显存 ， 也 
可 能 会 造成 系统 的 整体 性 能 降低 。 而 且 ， 过 多 的 分 配 内 存 给 显存 ， 那 么 当 
不 运行 3D 应 用 时 ， 就 是 一 种 内 存 浪费。 毕竟 ,用 户 的 使 用 模式 不 会 是 一 成 

` 变 的 ， 比 如 对 于 一 个 程序 员 来 说 ， 在 编程 之 余 也 可 能 会 玩 一 些 游戏 。 但 
征 我 们 显然 不 能 期 望 用 户 根据 具体 运行 应 用 的 情况 ， 每 次 都 进入 BIOS 修 改 
内 存 分 配给 显存 的 大 小 。 


为 了 最 优 利用 内 存 ， 一 种 方式 号 是 不 再 从 内 存 中 为 GPU 分 配 固定 的 显 
存 ， 而 是 当 GPU 知 要 时 ， 直 接 从 系统 内 存 中 分 配 ， 不 使 用 时 就 归还 给 系统 
使 用 。 但 是 CPU 和 和 GPU 毕竟 是 两 个 完全 独立 的 处 理 侨 ， 昌 然 现在 CPU 和 
GPU 正 在 走 融 合 之 路 ， 但 是 它们 依然 有 目 己 的 地 址 空间 。 显 然 ， 我 们 不 能 
允许 CPU 和 GPU 人 彼此 独立 地 去 使 用 物理 内 存 ， 这 样 必然 会 导致 冲突 ， 也 正 


是 因为 这 个 原因 ， 才 有 了 我 们 前 面 提 到 的 BIOS 会 从 物理 内 存 中 划分 一 块 区 
域 给 GPU， 这 样 CPU 和 GPU 才能 井 水 不 犯 河 水 ， 分 别 使 用 属于 目 己 的 存储 
区 域 。 


8.2.1 动态 显存 技术 


为 了 解决 这 个 矛盾 ，Intel 的 开发 者 们 开发 了 动态 显存 技术 (Dynamic 
Video Memory Technology) ， 相 比 于 以 前 在 内 存 中 为 GPU 开辟 专用 显存 ， 
使 用 动态 显存 技术 后 ， 显 存 和 系统 可 以 按 需 动态 共享 整个 主 存 。 


动态 显存 中 关键 的 是 GART (graphics address remapping table) ， 也 被 
称 为 GTT (graphics translation table) ， 它 是 GPU 直接 访问 系统 内 存 的 关 
键 。 事 实 上 ， 这 是 CPU 和 GPU 的 融合 过 程 中 的 一 个 产物 ， 最 终 ，CPU 和 
GPU 有 可 能 完全 实现 统一 的 寻 址 。 


GTT 就 是 一 个 表格 ， 或 者 说 殉 是 一 个 数组 ， 表 格 中 的 每 一 个 表 项 占用 4 
字 世 ， 或 者 指向 物理 内 存 中 的 一 个 页 面 ， 或 者 设置 为 无 效 。 整 个 GTT 所 能 
寻 址 的 范围 就 代表 了 GPU 的 逻辑 寻 址 空间 ， 如 512KB 大 小 的 GTT 可 以 寻 址 
512MB 的 显存 空间 (512K/4*4KB=512MB) ， 如 图 8-2 所 示 。 
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这 是 一 种 动态 按 需 从 内 存 中 分 配 显存 的 方式 ，GTT 中 的 所 有 表 项 不 必 
全 部 都 映射 到 实际 的 物理 内 存 ， 完 全 可 以 按 需 映 射 。 而 且 当 GTT 中 的 某 个 
表 项 指向 的 内 存 不 表 被 GPU 使 用 时 ， 可 以 收回 为 系统 所 用 。 通 过 这 种 动态 
按 需 分 配 的 方式 ， 达 到 系统 和 GPU 最 优 分 享 内 存 。 内 核 中 的 DRM 模 块 设 计 
了 特殊 的 互 斤 机制， 保证 CPU 和 GPU 独立 寻 址 物理 内 存 时 不 会 发 生 剖 突 。 


我 们 注意 到 ，GPU 是 通过 GTT 访 问 内存 的 〈 内 存 中 用 作 显 存 的 部 

分 ) ， 所 以 GPU 首先 要 访问 GTT， 但 是 ，GTT 也 是 在 内 存 中 。 显 然 ， 这 又 
是 一 个 先 有 鸡 还 是 先 有 和 蛋 的 问题 。 因 此 ， 需 要 另外 一 个 协调 人 出 现 ， 这 个 
协调 人 束 是 BIOS。 在 BIOS 中 ， 仍 然 需要 在 物理 内 存 中 划分 出 一 块 对 操作 系 
统 不 可 见 、 专 用 于 显存 的 存储 区 域 ， 这 个 区 域 通常 也 称 为 Graphics Stolen 
Memory。 但 是 相 比 于 以 前 动 加 分配 儿 百 兆 的 专用 显存 给 GPU， 这 个 区 域 要 
小 多 了 ， 一 般 几 MB 就 足 疾 ， 如 我 们 前 面 讨论 的 寻 址 512MB 的 显存 ， 只 需要 
一 个 512KB 的 GTT 表 。 


BIOS 负 责 在 Graphics Stolen Memory 中 建立 GTT 表 格 ， 初 始 化 GTT 表 格 
的 表 项 ， 更 重要 的 是 ，BIOS 负 责 将 GTT 的 相关 信息 ， 如 GTT 的 基 址 ， 写 入 
到 GPU 的 PCI 的 配置 寄存 器 (PCI Configuration Registers) ， 这 样 ，GPU 可 
以 直接 找到 GTT 了 “。BIOS 中 初始 化 GTT 的 代码 大 致 如 下 : 


6 THREEGERGESELeeay 1 

02 uint32 t gfxMemAddr, gttMemStart; 

03 volatile uint32 t *pGttEntry; 

04 

05 PCI WRITE (busno, deviceid, function number, 

06 PCI REG GTT, “GTT Base address” ); 
07 

08 gfxMemAddr =“Graphics Stolen Memory Address”，; 
09 gttMemStart =“GTT Base Address”: 

10 pGttEntry =“GTT Base Address” ，; 

J 

ee while (gfxMemAddr < gttMemStart) { 

六 *pGttEntry = (gfxMemAddr | 0x00000001);//addr + valid bit 
14 pGttEntry++; // next PTE 

15 gfxMemAddr += (4 * KB); // next page 

16 } 

ty 

18 while (pGttEntry < pGttEnd) { 

19 *pGttEntry = 0; // mark entry invalid 

20 pGttEntry++; // next PTE 

2 } 

S24} 


在 上 面 代 码 中 ， 变 量 gfxMemAddr 代 表 Graphics Stolen Memory 的 起 始 地 
址 ，gttMemStart 代 表 GTT 的 起 始 地 址 ， 指 针 pGttEntry 指 向 GTT 的 表 项 。 代 
码 第 8~10 行 初始 化 了 这 几 个 变量 ， 在 初始 化 时 ，pGttEntry 指 向 GTT 表 的 开 
始 ， 为 后 面 填充 GTT 表 作 准 备 。 


BIOS 从 物理 内 存 的 最 顶端 分 配 一 块 区 域 作为 Graphics Stolen Memory， 
然后 在 这 块 区 域 中 分 配 一 块 区 域 用 作 GTT， 并 将 GTT 所 在 的 地 址 写 入 GPU 
的 PCI 的 配置 寄存 器 ， 见 代码 第 5~6 行 。 操 作 系 统 启动 后 将 从 这 个 寄存 妖 中 


读 取 GTT 表 的 地 址 ， 其 中 PCI_REG_GTT 表 示 GPU 中 用 作 保 存 GTT 地 址 的 
PCI 配 置 寄存 器 。 


在 初始 化 时 ，GTT 只 需要 映射 Graphics Stolen Memory 区 域 即 可 ， 当 然 
GTT 占 用 的 空间 就 无 需 映 冉 了 。 代 码 第 12~16 行 就 是 映射 GSM 中 除 GTT 以 外 
的 显存 的 ， 即 gtxMemAddr 到 gttMemStart 之 间 的 部 分 。 


显存 的 其 余部 分 需要 时 动态 按 需 分 配 ， 所 以 代码 第 18~21 行 的 while 循 环 
忠 是 将 GTT 中 的 表 项 设置 为 无 效 ， 亦 即 尚 未 分 配 显 存 。 


在 操作 系统 启动 后 ， 显 存 的 分 配 和 回收 就 由 操作 系统 负责 了 ， 因 此 操 
作 系 统 需要 访问 GTT 。 但 是 ，GTTI 存 储 在 操作 系统 不 可 见 的 Graphics Stolen 
Memory 中 ， 那 么 操作 系统 如 何 找 到 GTT 呢 ?这 就 是 BIOS 将 GTT 的 地 址 设置 
到 GPU 的 PCI 配 置 寄存 侣 中 的 原因 。 在 操作 系统 局 动 后 ， 将 从 GPU 的 PCI 配 
置 寄 存 器 中 获取 如 GTT 的 基 址 等 信息 ， 代 码 如 下 : 


linux-3.7.4/drivers/char/agp/intel-gtt.c: 


static const struct intel gtt driver i915 gtt driver = { 
.gen = 3, 
.has pgtbl1 enable = 1， 
.Setup = i9xx setup, 
static const struct intel gtt driver sandybridge gtt driver = { 


static int i9xx setup (void) 


{ 


if (INTEL GTT GEN == 3) { 
u32. .gtt, addr; 


pci read config dword(intel private.pcideyv, 
I915_ PTEADDR, &gtt addr); 
intel private.gtt bus addr = gtt addr; 
} else { 


在 内 核 中 ， 对 于 Intel 不 同系 列 的 GPU， 都 有 相应 的 GTT 驱 动 ， 比 如 分 别 
有 针对 i8xx、i915、sandybridge 等 型 号 的 GTT 驱 动 模块 。 


以 i915 系 列 的 GPU 为 例 ， 我 们 在 其 GTT 驱 动 的 函数 i9xx_setup 中 可 见 ， 
其 使 用 pci_read_config_dword 从 GPU 的 PCI 的 配置 寄存 器 I915_ PTEADDR 中 
读 取 GTT 的 基 址 等 相关 信息 ， 然 后 将 i9xx_setup 读 取 的 GTT 的 地 址 保存 到 
gtt_bus_addr， 这 个 变量 就 是 用 来 保存 GPU 的 GTT 的 地 址 的 ， 后 面 我 们 在 讨 


论 显 存 绑 定时 会 再 次 见 到 这 个 变量 。 


当然 在 GTT 的 驱动 模块 中 ， 也 包含 操作 GTT 表 的 函数 ， 如 更 新 GTT 表 项 
的 函数 write_entry， 后 面 在 讨论 Buffer Object 绑 定 到 GTT 时 ， 我 们 会 看 到 这 
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8.2.2 Buffer Object 


与 CPU 相 比 ，GPU 中 包含 大 量 的 重复 的 计算 单元 ， 非 常 适合 如 像素 、 
光影 处 理 、3D 坐 标 变换 等 大 量 同 类 型 数据 的 密集 运算 。 因 此 ， 很 多 程序 为 
了 能 够 使 用 GPU 的 加 速 功能 ， 都 试图 和 GPU 直接 打交道 。 因 此 ， 系 统 中 可 
能 有 多 个 组 件 或 者 程序 同时 使 用 GPU， 如 Mesa 中 的 3D 驱 动 、X 的 2D 驱 动 以 
及 一 些 直 接 通 过 帧 缓冲 驱动 直接 操作 帧 缓冲 的 应 用 等 。 但 是 多 个 程序 并 发 
访问 GPU， 一 旦 逻辑 控制 不 好 ， 势 必 导 致 系统 工作 极 不 稳定 ， 严 重 者 甚至 
使 GPU 陷入 一 个 混乱 的 状态 。 


而 且 ， 如 果 每 个 希望 使 用 GPU 加 速 的 组 件 或 程序 都 需要 在 自身 的 代码 
中 加 入 操作 GPU 的 代码 ， 也 使 开发 过 程 变 得 非常 复杂 。 

于 是 ， 为 了 解决 这 一 乱 象 ， 开 发 者 们 在 内 核 中 设计 了 DRM 模 块 ， 所 有 
访问 GPU 的 操作 都 通过 DRM 统 一 进行 ， 由 DRM 来 统一 协调 对 GPU 的 访问 ， 
如 图 8-3 所 示 。 
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图 8-3 内核 中 的 DRM 模 块 


DRM 的 核心 是 显存 的 管理 ， 当 前 内 核 的 DRM 模 块 中 包含 两 个 显存 管理 
机 制 GEM 和 TTM。TTM 先 于 GEM 开 发 ， 但 是 Intel 的 工程 师 认 为 TTM 比 较 
复杂 ， 所 以 后 来 设计 了 GEM 来 替代 TTM。 目 前 内 核 中 的 ATI 和 NVIDA 的 
GPU 驱动 仍然 使 用 TTM， 所 以 GEM 和 TTM 还 是 共存 的 ， 但 是 GEM 占 据 主 导 
地 位 。 


GEM 抽 象 了 一 个 数据 结构 Buffer Object， 顾 名 思 义 ， 就 是 一 块 缓冲 区 ， 
但 是 比较 特别 ， 是 GPU 使 用 的 一 块 缓冲 区 ， 也 就 是 一 块 显存 。 比 如 一 个 颜 
色 缓 冲 的 像素 阵列 保存 在 一 个 Buffer Object， 绘 制 命令 以 及 绘制 所 需 数 据 也 
分 别 保存 在 各 目的 Buffer Object， 等 等 。 笔 者 实在 找 不 到 一 个 准确 的 中 文 词 
汇 来 代表 Buffer Object， 所 以 只 好 使 用 这 个 英文 名 称 。 开 发 者 习惯 上 也 将 


Buffer Object 人 简称 为 BO， 后 续 为 了 行文 方便 ， 我 们 有 时 也 使 用 这 个 简称 ， 
其 定义 如 下 : 


linux-3.7.4/include/drm/drmP.h: 
struct drm gem object { 


struct file *filp; 


int name; 
}; 
其 中 两 个 关键 的 字段 是 flp 和 name 。 


对 于 一 个 BO 来 说 ， 可 能 会 有 多 个 组 件 或 者 程序 需要 访问 它 。GEM 使 用 
Linux 的 共享 内 存 机 制 实现 这 一 需求 ， 字 段 filp 指 向 的 就 是 BO 对 应 的 共享 内 
存 ， 代 码 如 下 : 


linux-3.7.4/drivers/gpu/drm/drm gem.c: 


int drm gem object init(...) 


{ 


obj->filp = shmem file setup("drm mm object", size; ,..); 


Ws 


既然 多 个 组 件 需要 访问 BO，GEM 为 每 个 BO 都 分 配 了 一 个 名 字 。 当 然 
这 个 名 字 不 是 一 个 简单 的 字符 ， 它 是 一 个 全 局 唯一 的 ID， 各 个 组 件 使 用 这 
个 名 学 


名 字 来 访问 BO 。 


BO 可 以 占用 一 个 页 面 ， 也 可 以 占用 多 个 页 面 。 但 是 ， 通 常 BO 都 是 占用 
整数 个 页 面 ， 即 BO 的 大 小 一 般 是 4KB 的 整数 倍 。 在 i915 的 BO 的 结构 体 定 义 
中 ， 数 据 项 pages 指 向 的 就 是 BO 占用 的 页 面 的 链表 ， 这 里 并 不 是 使 用 的 简单 
的 链表 ， 结 构 体 sg_table 使 用 了 散 列 技术 。 有 具体 代码 如 下 : 


linux-3.7.4/drivers/gpu/drm/i915/i915 drv.h: 
struct drm i915 gem object { 


struct sg_ table *pages; 


为 了 可 以 被 GPU 访 问 ，BO 使 用 的 内 存 页 面 还 要 映射 到 GTT。 这 个 映射 
过 程 也 比较 直接 ， 就 是 将 BO 所 在 的 页 面 填 入 到 GTT 的 表 项 中 。 以 i915 为 
例 ， 下 面 这 个 函数 就 是 获取 BO 占据 的 页 面 : 


linux-3.7.4/drivers/gpu/drm/i915/i915 gem.c: 
static int 


i915 gem object get pages gtt (struct drm i915 gem object *obj) 


{ 
mapping = obj->base.filjp->f path.dentry->d inode->i mapping; 


for each sg(st->sgl, sg, page count, i) { 
page = shmem read mapping page gfp (mapping, i, gfp); 


sg_set pagel(lsg, page, PAGE SIZE, 0); 


} 


obj]->pages = st; 


注意 上 面 代码 中 使 用 黑体 标识 的 向 p， 它 指向 了 BO 对 应 的 共享 内 存 区 。 
显然 ， 获 取 BO 的 页 面 实际 就 是 获取 这 块 共享 内 存 的 页 面 ， 代 码 中 函数 


shmem_read_mapping_page_gfp 就 是 做 这 件 事 的 。 当 然 BO 可 能 对 应 多 个 页 
面 ， 所 以 这 里 是 一 个 循环 ， 并 将 每 个 获取 的 页 面 放 到 散 列 表 中 ， 最 后 使 BO 
中 的 指针 pages 指 向 这 个 页 面 散 列 表 。 


将 BO 的 对 应 页 表 写 入 到 GTT 的 表 项 中 的 代码 如 下 : 


linux-3.7.4/drivers/gpu/drm/i915/i915 gem gtt.c: 


void i915 gem gtt bind object (struct drm i915 gem object *obj,...) 


{ 


intel gtt insert sg entries(obj=>pages, ...); 


函数 intel_gtt_insert_sg_entries 在 内 核 的 mtel 的 GTT 驱 动 模块 中 ， 其 实现 
代码 如 下 : 


linux-3.7.4/drivers/char/agp/intel-gtt.c: 


void intel] gtt insert sg entries(struct sg table *st, ...) 


{ 


for each sg(st->sgl, sg, st->nents, i) { 
len = sg _ dma len(sg) >> PAGE SHIFT; 
for (m= 0; m < len; m++) { 
dma addr t addr = sg dma address(sg) + (m << PAGE SHIFT); 
intel private.driver->write entry(addr, j, flags); 
ty 


责 数 intel_gtt_insert_sg_entries 人 遍历 BO 对 应 页 面 的 散 列 表 ， 依 次 调用 
GTT 张 动 中 的 函数 write_entry 将 页 面 的 地 址 写 入 到 GTT 的 表 项 中 。GPU 当 然 
不 能 理解 CPU 使 用 的 虚拟 地 址 了 ， 所 以 函数 sg_dma_address 返 回 的 是 页 面 的 
物理 地 址 。i915 系 列 GPU 的 GTT 驱 动 的 write_entry 函 数 如 下 : 


linux-3.7.4/drivers/char/agp/intel-gtt.c: 
static const struct intel gtt driver i915 gtt driver = { 
.write entry = i830 write entry, 


static void i830 write entryl(dma addr t addr,unsigned int entry,...) 


writel (addr | pte flags, intel private.gtt + entry),; 


函数 i830_write_entry 逻 辑 非常 简单 ， 尤 其 是 对 于 了 解 驱 动 的 读者 而 言 
更 是 如 此 ， 其 与 我 们 癌 某 个 内 存 地 址 处 赋值 无 本 质 区 别 。 这 里 ，addr 束 是 页 
面 的 地 址 ，intel_private.gtt 是 GTT 的 基 址 ，entry 是 GTT 中 具体 的 表 项 。 


读者 可 能 有 个 疑问 : GTT 不 是 在 BIOS 划 分 给 GPU 专 用 的 Graphics Stolen 
Memory 中 吗 ? 那么 CPU 怎 么 可 以 寻 址 GTT， 更 新 GTT 的 表 项 呢 ? 内 核 中 的 
GTT 驱 动 模块 已 经 考虑 到 了 这 点 ， 在 GTT 模 块 初始 化 时 ， 其 使 用 ioremap 将 
GTT 所 在 地 址 映射 到 了 CPU 的 地 址 空间 ， 代 码 如 下 所 示 : 


linux-3.7.4/drivers/char/agp/intel-gtt.c: 
static int intel gtt init (voiqd) 


{ 


if (INTEL GTT GEN < 6 && INTEL GTT GEN > 2) 


intel private.gtt = ioremap wc( 
intel private.gtt bus addr, gtt map size),; 
if (intel private.gtt == NULL) 
intel private.gtt = ioremap (intel private.gtt bus adgdr, 


gtt map size); 


看 到 变量 gtt_bus_addr 是 不 是 很 熟悉 ? 没 错 ， 在 前 面 讨论 i915 的 GTT 驱 
动 中 的 函数 i9xx_setup 时 我 们 看 到 ，i9xx_setup 从 GPU 的 PCI 配 置 寄存 器 读 取 
的 GTT 的 基 址 就 记录 在 这 个 变量 中 。 


综 上 ， 我 们 看 到 ，BO 本 质 上 就 是 一 块 共享 内 存 ， 对 于 CPU 来 说 BO 与 其 
他 内 存 没 有 任何 差别 ， 但 是 BO 又 是 特别 的 ， 它 被 映射 进 了 GTT， 所 以 它 既 
可 以 被 CPU 寻 址 ， 也 可 以 被 GPU 寻 址 ， 如 图 8-4 所 示 。 
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图 8-4 Buffer Object 


为 了 方便 程序 使 用 内 核 的 DRM 模 块 ， 开 发 者 们 开发 了 库 libdrm 。 在 库 
libdrm 中 BO 的 定义 如 下 : 


libdrm-2.4.35/intel/intel bufmgr.h: 
atric Grm titel 6 4 

i long offset; 

si *virtual; 


}; 


其 中 两 个 重要 的 数据 项 是 offset 和 virtual 。 


事实 上 ，BO 只 是 DRM 抽 象 的 在 内 核 空间 代表 一 块 显存 的 一 个 数据 结 
构 。 那 么 GPU 是 怎么 找到 BO 的 呢 ? 如同 CPU 使 用 地 址 寻 址 一 个 内 存单 元 一 
样 ，GPU 也 使 用 地 址 寻 址 。GPU 根 本 不 关心 什么 BO， 它 只 认 显 存 的 地 址 。 
因此 ， 每 一 个 BO 在 显存 的 地 址 空间 中 ， 都 有 一 个 唯一 的 地 址 ，GPU 通 过 这 
个 地 址 寻 址 ， 这 就 是 offset 的 意义 。offset 是 BO 在 显存 地 址 空间 中 的 虚拟 地 
址 ， 显 存 使 用 线性 地 址 寻 址 ， 任 何 一 个 显存 地 址 都 是 从 起 始 地 址 的 偏 移 ， 
这 就 是 offset 命 名 的 由 来 。offset 通 过 GTT 即 可 映射 到 实际 的 物理 地 址 。 当 我 
们 向 GPU 发 出 命令 访问 某 个 BO 时 ， 就 使 用 BO 的 成 员 offset 。 


有 时 需要 将 BO 映射 到 用 户 空间 ， 其 中 数据 项 virtual 就 是 记录 映射 的 基 
由 


前 面 ， 我 们 讨论 了 BO 的 本 质 。 下 面 我 们 从 使 用 的 角度 看 一 看 CPU 与 
GPU 又 是 如 何 使 用 BO 的 。BO 二 显存 的 基本 单元 ， 所 以 从 保存 像素 阵列 的 帧 


缓冲 ， 到 CPU 下 达 给 GPU 的 指令 和 数据 ， 全 部 使 用 BO 承载 。 下 面 ， 我 们 分 
别 从 软件 浑 染 和 硬件 演 染 两 个 角度 看 看 BO 的 使 用 。 


(1) 软件 泻 染 


当 GPU 不 文 持 某 些 绘制 操作 时 ， 代 表 帆 缓冲 的 BO 将 被 映射 到 用 户 罕 
间 ， 用 户 程序 直接 在 BO 上 使 用 CPU 进行 软件 绘制 。 从 这 里 我 们 也 可 以 看 
出 ，DRM 巧 妙 的 设计 使 得 BO 非常 方便 地 在 显存 和 系统 内 存 之 间 进 行 角 色 切 
ee 


(2) 硬件 泻 染 


当 GPU 支 持 绘 制 操 作 时 ， 用 户 程序 则 将 命令 和 数据 等 复制 到 保存 命令 
和 数据 的 BO， 然 后 GPU 从 这 些 BO 读 取 命 令 和 数据 ， 按 照 BO 中 的 指令 和 数 


据 进行 泻 染 。 


库 libdrm 中 提供 了 画 数 drm_intel _bo_subdata 和 
drm_intel bo_get_subdata， 在 程序 中 一 般 使 用 这 两 个 函数 将 用 户 空 间 的 命令 
和 数据 复制 到 内 核 空 间 的 BO 读者 也 会 见 到 dri_bo_subdata 和 
dri bo_get_subdata。 对 于 Intel 的 驱动 来 说 ， 后 面 两 个 函数 分 别 是 前 面 两 个 函 
数 的 别名 而 已 。 后 面 讨 论 具 体 泻 染 过 程 时 ， 我 们 会 经 党 看 到 这 几 个 函数 。 


8.3”2D 演 染 


这 一 节 ， 我 们 结合 Xx 窗口 系统 ， 讨 论 2D 程 序 的 泻 染 过 程 。 我 们 可 以 形 
象 地 将 2D 泻 染 过 程 比喻 为 绘画 ， 其 中 有 两 个 关键 的 地 方 ， 一 个 是 画布 ， 男 


外 一 个 是 画笔 。 


X 服 务 右 局 动 后 ， 将 加 载 GPU 的 2D 驱 动 ，2D 驱 动 将 请 求 内 核 中 的 DRM 
模块 创建 帧 缓冲 ， 这 个 帧 缓冲 就 相当 于 画布 。 然 后 X 服 务 器 按照 绘画 需要 ， 
从 画笔 盒子 中 挑选 合适 


天 的 画笔 进行 绘 


X 的 画笔 保存 在 结构 体 GCOps 中 ， 其 中 包含 了 基本 的 绘制 操作 ， 如 绘制 
矩形 的 PolyRectangle， 绘 制 圆 弧 的 PolyArc， 绘 制 实 心 多 边 形 的 
FillPolygon， 等 等 。 代 码 如 下 : 

xorg-server-1.12.2/include/gcstruct.h: 

typedef struct GCOps { 
wl Mole gen ae ,sw 
void (*PolyArc) (DrawablePtr /*pDrawable */ ，...); 
void (*FillPolygon) (Drawableptr /*pDrawable */ ，...); 
void (*PolyFillRect) (Drawableptr /*pDrawable */ ， ...); 


} i 
最 初 ， 这 些 绘制 操作 均 由 CPU 人 负 足 完成 ， 也 就 古 我 们 通 肖 所 说 的 软件 
渲染 。X 中 的 全 层 束 是 软件 洽 染 的 实现 ， 代 码 如 下 : 


xorg-server-1.12.2/fb/fbgc.c: 


const GCOps fbGcops = f 
fbFillSpans, 


fbpolySegment, 
fbpolyRectangle, 
fbpolyArc, 
miFillPolygon, 


ys 


但 是 随 着 GPU 的 不 断 发 展 ， 其 计算 能 力 越 来 越 强 。 于 是 X 的 开发 者 们 不 
断 改 进 X 的 演 染 部 分 ， 硕 望 能 充分 利用 GPU 擅长 的 图 形 操作 以 大 幅 提 高 计算 
机 的 图 形 能 力 ， 而 又 可 以 解放 CPU， 使 其 专心 于 控制 逻辑 。 也 殉 是 说 ，X 的 
开发 者 们 希望 画笔 盒子 中 的 画笔 更 多 地 来 目 GPU。 


当然 ， 任 何事 物 都 不 是 一 跃 而 就 的 ，GPU 的 泻 染 能 力也 是 螺旋 演进 
的 ， 对 于 GPU 尚未 实现 的 或 者 相 比 来 说 CPU 更 适合 的 泻 染 操作 还 是 需要 
CPU 来 完成 ， 因 此 ，X 的 演 染 架构 也 随 着 GPU 的 演进 不 断 地 改进 。 在 
XFree86 3.3 的 时 候 ，X 的 开发 者 设计 了 XAA (XFree86 Acceleration 
Architecture) 架构 ;在 X.Org Server 6.9 版 本 ， 开 发 者 用 改进 的 EXA 取 代 了 
XAA; 当 DRM 中 使 用 了 GEM 后 ，Intel 的 GPU 驱动 开发 者 们 重新 实现 了 
EXA， 并 命名 为 UXA (Unified Acceleration Architecture) ; 随 着 Intel 推 出 


Sandy Bridge 及 ivy Birdge 忆 片 组 ，Intel 又 开发 了 SNA (SandyBridge's New 


Acceleration ) 


后 续 ， 我 们 以 成 熟 且 稳 定 的 UXA 为 例 进行 讨论 。 在 UXA 架 构 下 ，X 的 


xf86-video-intel-2.19.0/uxa/uxa-accel .c: 


CoOnst GCOpS Uxa Ope 2 
uxa fill spans, 


uxa poly lines, 

uxa poly segment， 
mipolyRectangle, 
uxa check poly arc, 
miFillPolygon, 


我 们 看 到 uxa_ops 包 含 在 mmtel 的 GPU 张 动 中 ， 当 然 ， 这 是 非常 合理 的 ， 
因为 只 有 GPU 上 自己 最 清楚 哪些 泻 染 自己 可 以 胜任 ， 哪 些 还 需要 CPU 来 负 
责 。 在 uxa_ops 中 ， 有 一 部 分 画笔 来 目 GPU， 另 外 一 部 分 来 目 CPU 。 


对 于 每 一 个 绘制 操作 ，UXA 首 先 检查 GPU 是 否 支持 这 个 绘制 操作 ， 或 
者 说 在 某 些 条 件 下 ， 对 于 这 个 绘制 操作 ，GPU 演 染 的 比 CPU 更 快 。 如 果 
GPU 文 持 这 个 绘制 操作 ，UXA 首 先 将 绘制 的 命令 翻译 为 GPU 可 以 识别 的 指 
令 ， 并 将 这 个 指令 、 绘 制 所 需 的 相关 数据 ， 以 及 保存 像素 阵列 的 BO 在 显存 
地 址 空间 中 的 地 址 ， 一 同 保存 在 用 户 空间 的 批量 缓冲 (Batch Buffer) ， 然 
后 通过 DRM 将 用 户 空间 的 批量 缓冲 复制 到 内 核 为 批量 缓冲 创建 的 BO， 之 后 
通知 GPU 从 BO 中 读 取 指令 和 数据 进行 绘制 。 实 际 上 ，DRM 按 照 Intel GPU 的 
要 求 在 批量 缓冲 和 GPU 之 间 还 组 织 了 一 个 环形 缓冲 区 (Ring buffer) ， 但 是 


我 们 暂时 忽略 它 ， 这 对 于 理解 2D 泻 染 过 程 没 有 任何 影响 ， 后 面 在 讨论 3D 泻 
染 过 程 时 ， 我 们 会 位 单 的 讨论 这 个 环形 缓冲 区 。 


如 果 GPU 不 文 持 这 个 绘制 操作 ， 那 么 UXA 将 代表 帧 缓冲 的 BO 映射 到 X 
服务 器 的 用 户 空间 ，X 服 务 器 借助 tb 层 中 的 实现 ， 使 用 CPU 进 行 绘制 。 


也 就 是 说 ，UXA 在 人 和 GPU 加 速 的 上 面 封 狠 了 一 层 ， 其 根据 具体 绘制 
动作 选择 使 用 来 目 GPU 的 画笔 或 来 目 CPU 的 画笔 。 


综 上 ，X 的 2D 演 染 过 程 如 图 8-5 所 示 。 
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图 8-5 X 的 2D 洽 染 过 程 


不 知 读者 是 否 注意 到 ， 无 论 是 了 bGCOps， 还 是 uxa_ops， 其 中 均 有 个 别 
的 绘制 函数 以 "mi" 开 头 。 这 些 以 "mi" 开 头 的 函数 包含 在 X 的 mi 层 中 。mi 是 


Machine Independent 的 缩写 ， 顾 名 思 义 ， 有 是 与 机 融 无 关 的 实现 。 笔 者 没有 找 
到 X 中 关于 这 个 层 的 非常 明确 的 解释 ， 但 是 根据 mi 中 的 代码 来 看 ， 其 中 的 给 
致 画 数 根据 不 同 的 绘制 条 件 ， 被 拆 分 为 调用 其 他 GCOps 中 的 绘制 画 数 。 


基本 上 ， 拆 分 的 原因 无 外 乎 GPU 支 持 的 绘制 原 语 有 限 ， 所 以 有 些 绘制 
操作 需要 分 解 为 GPU 可 以 文 持 的 动作 。 或 者 出 于 绘制 效率 的 考虑 ， 将 某 些 
绘制 操作 拆 分 为 效率 更 好 的 绘制 原 语 。 因 此 ，X 将 这 些 与 具体 绘制 实现 无 关 
的 代码 剥离 到 一 个 单独 的 模块 mi 中 。 从 这 个 角度 或 许 能 解释 X 为 什么 将 这 个 
层 命名 为 Machine Independent 。 


8.3.1 创建 前 缓冲 


在 X 环 境 下 ， 在 不 开启 复合 (Composite) 扩展 的 情况 下 ， 所 有 程序 共 
享 一 个 前 缓冲 。 对 于 2D 程 序 ， 所 有 的 绘制 动作 生成 的 图 像 的 像素 阵列 最 终 
都 输出 到 这 个 前 缓冲 上 ， 窗 口上 只 不 过 是 前 缓冲 中 的 一 块 区 域 而 已 。 


但 是 一 旦 开局 了 复合 扩展 ， 那 么 每 个 窗口 都 将 被 分 配 一 个 离 屏 
(offscreen) 的 缓冲 ， 类 似 于 OpenGL 环 境 中 的 后 缓冲 。 应 用 将 生成 的 像素 
阵列 输出 到 这 个 离 屏 的 缓冲 中 ， 在 绘制 完成 后 ，X 服 务 右 将 癌 复 合 管理 右 
(Composite Manager) 发 送 Damage 事 件 ， 复 合 管理 器 收 到 这 个 事件 后 ， 将 
离 屏 缓冲 区 的 内 容 合成 到 前 缓冲 。 为 了 避免 复合 扩展 干扰 我 们 探讨 疼 形 洽 
染 的 本 质 ， 在 讨论 2D、 包 括 后 面 的 3D 演 染 时 ， 我 们 都 不 考虑 复合 扩展 开启 
的 情况 。 


在 X 中 ，Window 和 Pixmap 是 两 个 绘制 发 生 的 地 方 ，Window 代 表 屏 幕 上 
的 窗口 ，Pixmap 则 代表 离 屏 的 一 个 存储 区 域 。 所 以 目 然 而 然 的 ，X 使 用 数据 
结构 Pixmap 来 表示 前 缓冲 。 因 为 这 个 前 绥 冲 对 应 整个 屏幕 ， 而 且 不 属于 茶 
一 个 应 用 ， 因 此 开发 者 也 将 代表 前 缓冲 的 这 个 Pixmap 称 为 Screen Pixmap 。 
后 续 为 了 行文 方便 ， 我 们 有 时 也 使 用 Screen Pixmap 这 个 词 来 代表 前 缓冲 的 
这 个 Pixmap 对 象 。 显 然 ， 这 个 Screen Pixmap 也 是 显示 器 (Screen) 的 资源 ， 


所 以 X 将 其 保存 到 了 代表 显示 亏 的 结构 体 _Screen 中 : 


xorg-server-1.12.2/include/scrnintstr.h: 
typedef struct Screen { 
pointer devPrivate,; 


} ScreenRec; 


其 中 指针 devPrivate 指 问 这 个 前 缓冲 ， 后 面 看 到 如 GetScreenPixmap 的 落 
数 ， 束 是 从 _Screen 中 获取 前 缓冲 。 


Pixmap 并 不 只 是 简单 地 抽象 为 像素 阵列 ， 还 要 包含 一 些 解释 像素 数组 
所 需要 的 信息 ， 比 如 图 形 的 高 度 、 宽 度 、 格 式 等 ， 其 定义 如 下 : 


XOorg-server-1.12.2/include/pixmapstr.h: 


typedef struct Pixmap { 
DrawableRec drawable,; 
PrivateRec *devPrivates,; 


} PixmapRec; 


结构 体 _Pixmap 中 的 指针 devPrivates 指 向 保存 前 缓冲 的 像素 阵列 的 BO 。 
但 是 Intel GPU 的 2D 驱 动 为 了 记录 更 多 信息 ， 在 BO 基础 上 封 汐 了 一 层 ， 封 效 
后 的 数据 结构 为 intel_pixmap。 所 以 ， 最 终 Pixmap 中 的 devPrivate 指 癌 的 并 不 
是 一 个 裸 BO， 而 是 在 BO 上 包围 了 一 层 的 一 个 intel_pixmap 对 象 。 结 构 体 
intel_pixmap 的 定义 如 下 : 


xf86-video-intel-2.19.0/src/intel.h: 


struct intel pixmap { 
dri bo *bo; 


}; 


其 中 指针 bo 指 问 的 束 是 保存 前 绥 促 的 像素 阵列 的 BO 。 
1. 创 建 前 缓冲 的 BO 


前 绥 冲 的 BO 是 在 X 服 务 器 启动 过 程 中 ，2D 了 驱动 初始 化 输出 设备 时 ， 调 
用 函数 intel_allocate_framebuffer 创 建 的 ， 具 体 代 码 如 下 : 


xf86-video-intel-2.19.0/src/intel _ memory .c: 


drm intel bo *intel allocate framebuffer(...) 


{ 


front buffer = drm intel bo alloc tiled(intel->bufmgr, 
"front buffer", width, height, intel->cpp, 
&tiling mode, &pitch, 0); 


函数 drmm_intel bo_alloc tiled 是 库 libdrm 提 供 的 API， 在 库 libdrm 中 对 应 


的 函数 是 drm_intel _gem_bo_alloc_internal : 


libdrm-2.4.35/intel/intel bufmgr gem.c: 


static drm intel bo *drm intel gem bo alloc internal(...) 


{ 


ret = drmIoctl (bufmgr gem->fda， 
DRM IOCTL I915 GEM CREATE, &create); 


由 代码 可 知 ， 画 数 drm_intel_gem_bo_alloc_internal 就 是 向 内 核 中 的 DRM 
模块 申请 创建 前 缓冲 的 BO。 


2. 将 前 缓冲 保存 到 屏幕 对 象 


在 创建 了 前 缓冲 的 BO 后 ，X 服 务 器 为 前 缓冲 创建 了 Pixmap 对 象 ， 即 
Screen Pixmap。2D 驱 动 则 创建 了 封闭 前 缓冲 的 BO 的 intel_pixmap 对 象 。 并 
且 ，X 也 将 各 个 对 象 天 联 了 起 来 。 


又 服务 器 创建 Pixmap 对 象 的 代码 如 下 : 


xorg-server-1.12.2/mi/miscrinit.c: 


Bool miCreateScreenResources (ScreenPtr pScreen) 


{ 


pPixmap = (*pScreen->CreatePixmap) (pScreen, ...); 
value = (pointer) pPixmap; 
pScreen->devPrivate = value; /* pPixmap or pbits */ 


return TRUE; 


函数 miCreateScreenResources 首 移 创 建 了 一 个 Pixmap 对 象 ， 这 个 对 象 惑 
是 Screen Pixmap。 然 后 将 屏幕 对 象 中 的 指针 devPrivate 指 向 Screen Pixmap 。 


2D 驱 动 中 创建 intel_pixmap 对 象 的 代码 如 下 : 


xf86-video-intel-2;:19,.0/src/intel uxa.;ce; 


Bool intel uxa create screen resources (ScreenpPtr screen) 


{ 
dri bo *bo = intel-=->front buffer; 


PixmapPtr pixmap = Screen->GetScreenPixmap (screen); 
intel set pixmap bol(pixmap, bo); 


在 上 面 的 代码 中 ， 函 数 GetScreenPixmap 的 目的 就 是 获取 Screen 
Pixmap。 其 中 函数 intel_set_pixmap_bo 的 代码 如 下 : 


xf86-video-intel-2.19.0/src/intel uxa.c: 
void intel set pixmap bo(PixmapPtr pixmap, dri bo * bo) 
{ 
struct intel pixmap *priv:; 
priv = calloc(l1, sizeof (struct intel pixmap)); 


priv=>bo = bo; 


intel set pixmap private (pixmap, priv); 


函数 intel_set_pixmap_bo 首 多 创建 了 一 个 intel_pixmap 对 象 ， 这 个 
intel_pixmap 对 象 中 的 指针 bo 指向 的 函数 的 第 2 个 实 参 bo 正 是 保存 前 缓冲 像素 
阵列 的 BO。 然 后 调用 函数 intel_set_pixmap_private 将 intel_pixmap 与 该 函数 的 
第 1 个 实 参 ， 即 Screen Pixmap 关 联 起 来 。 


窗口 与 前 缓冲 的 绑 定 


前 缓冲 已 经 建立 起 来 了 ， 但 是 ， 显 然 需 要 将 窗口 与 前 缓冲 关联 起 来 ， 
否则 在 窗口 上 的 绘制 并 不 能 体现 到 屏幕 上 。 我 们 在 编写 具有 图 形 界 面 的 程 
序 时 ， 在 绘制 之 前 首先 需要 创建 绘制 所 在 的 窗口 。 恰 恰 就 是 在 创建 窗口 
时 ， 窗 口 与 前 缓冲 绑 定 了 。 我 们 来 看 一 下 X 中 创建 窗口 的 函数 
fbCreateWindow: 


Xxorg-server-1.12.2/fb/fbwindow.c: 


Bool fbCreateWindow (WindowPtr pWin) 
{ 
QixSetPrivate(&pWin->devPrivates，fbGetWinPrivateKev() ， 
fbGetScreenPixmap (pWin->drawable.pScreen)); 


fbCreateWindow 调 用 函数 fbGetScreenPixmap 获 取 Screen Pixmap， 并 将 
窗口 对 象 与 Screen Pixzmap 绑 定 。 


显然 ， 所 谓 的 创建 窗口 事实 上 就 是 将 窗口 与 前 缓冲 关联 起 来 ， 以 后 凡 
古 发 生 在 窗口 上 的 绘制 ， 痢 将 直接 绘制 到 前 缓冲 中 。 


8.3.2 ”GPU 泻 染 


GPU 泻 染 ， 也 就 是 我 们 通常 所 说 的 硬件 加 速 ， 从 软件 的 层面 所 做 的 工 
作 束 是 将 数学 模型 按照 GPU 的 规定 ， 翻 译 为 GPU 可 以 识别 的 指令 和 数据 ， 
传递 给 GPU， 生 成 像素 阵列 等 图 像 密 集 型 计算 则 由 GPU 人 负责 完成 。 可 见 ， 
当 使 用 GPU 进 行 泻 染 时 ， 在 软件 层面 ， 实 质 上 束 是 组 织 命令 和 数据 而 已 。 


Intel GPU 的 2D 驱 动 是 如 何 将 这 些 命令 和 数据 传递 给 GPU 的 呢 ? 读 者 一 
定 想到 了 BO。 在 Intel GPU 的 2D 驱 动 中 ， 定 义 了 使 用 了 一 种 所 谓 的 批量 缓冲 
来 保存 这 些 命 令 和 数据 ， 这 里 所 谓 的 批量 就 是 将 驱动 准备 命令 和 数据 放 到 
这 个 缓 促 ， 然 后 批量 地 让 GPU 来 读 取 ， 这 就 是 批量 缓冲 的 由 来 。 批 量 缓冲 
的 相关 定义 在 结构 体 intel_screen_private 中 : 


xf86-video-intel-2.19.0/src/intel.h: 
typedef struct intel screen private { 


Ulint32 €t bateh pErLL2096]; 
unsigned int batch used; 


dri bo *batch bo; 


} intel screen private; 


在 结构 体 intel_screen_private 中 ， 数 组 batch_ptr 是 X (准确 地 说 是 2D 驱 
动 ) 在 用 户 空间 使 用 的 组 织 命令 和 数据 的 地 方 ， 指 针 batch_bo 则 指 癌 内 核 空 
间 保 存 批量 缓冲 数据 的 BO。2D 张 动 将 相关 的 命令 和 数据 组 织 在 数组 


batch_ptr 中 ， 然 后 将 数组 batch_ptr 中 的 数据 复制 到 batch_bo 指 癌 的 内 核 空间 
中 的 BO 中 ， 供 GPU 来 读 取 。 


2D 了 驱动 的 代码 中 为 了 方便 ， 也 定义 了 几 个 操作 批量 缓冲 的 宏 ，— 典 型 的 
有 如 下 的 OUT_BATCH 和 OUT_RELOC_PIXMAP_FENCED: 


xf86-video-intel-2.19.0/src/intel batchbuffer.h: 


#define OUT BATCH (dword) intel batch emit dword(intel, dword) 
#define OUT RELOC PIXMAP FENCED (pixmap, reads, write, delta) \ 
intel batch emit reloc pixmap (intel, pixmap, reads, \ 
write, delta, 1) 


static inline void intel batch emit dworad( 
intel. screen private *intel, yint32 t dword) 


} 


intel->batch ptr[lintel->batch used++] = dword; 


static inline void intel batch emit zeloc 人 
intel screen private *intel, dri bo * bo,...) 


intel batch emit dword(intel, bo->offset + delta); 


安 OUT_BATCH 将 命令 或 者 数据 写 入 数组 batch_ptr， 安 
OUT RELOC_PIXMAP_ FENCED 将 BO 的 在 GPU 地 址 空间 中 的 虚拟 地 址 写 
入 数组 batch_ptr 。 


接 下 来 ， 我 们 以 具体 的 绘制 方法 miPolyRectangle 为 例 ， 讨 论 2D 驱 动 如 
何 使 用 GPU 进行 绘制 ， 也 就 是 我 们 通常 所 说 的 硬件 加 速 ， 具 体 代 码 如 下 : 


xorg-server-1.12.2/mi/mipolyrect.c: 


01 void mipolyRectangle(...) 
02 { 


04 if (pGC->lineStyle == LineSolid && pGC->joinSstyle == 

05 JoinMiter && pGC->lineWwidth != 0) { 

07 (*pGC->ops->PolyFillRect) (pDraw, pGC, 七 - tmp, tmp); 
08 free( (pointer) tmp); 

09 } 

10 else { 


12 (*pGC->ops->Polylines) (...); 


根据 不 同 的 绘制 条 件 ， 函 数 miPolyRectangle 将 绘制 矩形 的 动作 进行 了 
拆 分 ， 拆 分 的 目的 是 选择 最 合适 的 绘制 方式 进行 绘制 。 这 个 拆 分 方法 不 依 
赖 于 任何 具体 硬件 ， 因 此 ，X 将 这 个 拆 分 过 程 放 到 mi 层 中 。 


如 果 和 矩形 的 线性 是 实心 填充 的 ， 且 线段 交汇 处 是 尖 角 (JoinMiter) 风 
格 的 ， 并 且 宽 度 不 为 0， 那 么 使 用 方法 PolyFillRect 绘 制 ， 见 代码 第 4~9 行 。 
否则 ， 使 用 方法 Polylines 绘 制 ， 如 代码 第 10~14 行 所 示 。 


以 PolyFillRect 为 例 ， 其 在 UXA ( 即 uxa_ops) 中 对 应 的 具体 函数 是 


uxa_poly_fill_rect: 


xf86-video-intel-2.19.0/uxa/uxa-accel .c: 


04 Btatie vold, Ura pOLyY Hl] Teet (sw) 

0 

03 到 

04 if (pGC->fillstyle != FillSolid && ...) { 

05 goto fallback; 

06 } 

08 if (!(*uxa screen->info->prepare solid) (pPixmap, ...)) { 
09 fallback: 

10 Uxa_ check poly fill rect (pDrawable, pGC, nrect, prect); 
a goto out; 

12 } 


14 (*uxa screen->info->solid) (pPixmap, 
Ts 1 OEES WL FF VOEE; 22 + NOEE, V2 VOEE)S 


函数 uxa_poly_fill_rect 首 先 检查 各 种 绘制 条 件 以 确认 是 否 适 合 使 用 GPU 
进行 绘制 ， 如 代码 第 4~7 行 所 示 。 如 果 适 合 使 用 GPU 进 行 绘制 ， 则 陆续 调用 
函数 prepare_solid 和 solid 为 GPU 准备 指令 和 数据 ， 下 面 我 们 会 重点 讨论 这 两 
KK o 


> 
加 


否则 ， 正 如 第 5 行 代 码 所 示 ， 跳 转 到 标签 fallback 处 ， 即 代码 第 9 行 ， 使 
用 函数 uxa_check_poly_fill_rect 进 行 绘制 ， 这 个 函数 实际 是 使 用 CPU 进行 绘 
制 的 ， 我 们 将 在 8.3.3 节 进行 讨论 。 


UXA 中 的 函数 指针 solid 指 向 intel _uxa_solid: 


xf86-video-intel-2.19.0/src/intel uxa.c: 


01 static void intel] uxa solid(PixmapPtr pixmap, int Xx1， 


02 Ln wl dnt Zr Wnt 2 

03 { 

04 

05 { 

06 BEGIN BATCH BLT(6); 

07 

08 cmd = XY _ COLOR BLT CMD; 

09 yi 

10 OUT_ BATCH (cmd) ; 

Tl 

J OUT BATCH(intel->BR[13] | pitch); 

了 OUT BATCR( (YL << 16) | (x & DxEfEE)).; 
14 QUT BATCH( (y2 <& 16) | (x2 B DxEEEFE) ) 7 
15 OUT_ RELOC PIXMAP FENCED (pixmap, 

16 I915_ GEM DOMAIN RENDER, I915 GEM DOMAIN RENDER, 0); 
7 OUT BRATCH (intel->BR[16]) ; 

18 ADVANCE BRATCH () ; 

19 } 

20 3 


根据 前 面 讨论 的 批量 缓冲 以 及 为 操作 批量 缓冲 封装 的 几 个 宏 ， 读 者 一 
定 已 经 看 出 来 了 ， 上 面 的 代码 是 在 组 织 批量 缓冲 在 用 户 空 间 的 数组 
batch_ptr。 那 么 函数 intel_uxa_solid 向 batch_ptr 中 填 入 各 项 的 意义 是 什么 呢 ? 
这 个 显然 要 参考 Intel GPU 的 指令 格式 。 根 据 第 8 行 代码 可 见 ，2D 张 动 发 送 给 
GPU 的 指令 是 XY_COLOR_BLT， 该 指令 的 功能 是 对 目标 区 域 以 指定 颜色 填 


充 。Intel GPU 的 指令 XY_COLOR_BLT 的 格式 如 表 8-1 所 示 。 


表 8-1 Intel GPU 指令 XY_COLOR_BLT 的 格式 


IE 亲 过 
| 0 BT 可 
0 = BR00 省 仿 操作 码 : 50h 
色 深 :00=8 位 ;01=16 位 ;… 
1= BR13 15:00 | 标 图 像 的 跨度 
31:16 导 标 区 域 顶 部 坐标 ( Y1 ) 
7 一 BR22 
15:00 | 标 区 域 左 侧 坐 标 (X1 ) 
目标 区 城 克 部 坐标 (Y2) 
3 = BR23 a 
| 标 区 域 古 侧 毕 标 (X2 ) 
4= BR09 31:00 目标 区 域 基 址 
BR | 5 


(来 源 于 “Intel OpenSource HD Graphics Programmer”s Reference Manual (PRM) Volume 1 Part 5: Graphics Core 
— Blitter Engine (SandyBridge) May 2011 Revision 1.0”) 


下 面 我 们 结合 表 8-1 来 分 析 函 数 intel_uxa_solid 组 织 批量 缓冲 的 过 程 。 


1) 由 表 8-1 可 见 ， 指 令 XY_COLOR_BLT 包 含 6 个 双 字 (DWord) ， 第 10 
行 代码 填充 的 是 第 0 个 双 字 ， 其 中 "BR00" 是 什么 意思 呢 ? 事实 上 ，GPU 内 部 
分 为 多 个 微 核 ， 处 理 不 同 的 命令 ， 处 理 2D 指 令 的 微 核 称 为 BLT3 引 | 擎 

(Engine) 。 对 于 每 个 2D 指 令 ， 每 个 双 字 实际 上 分 别 被 送 往 BLT 引 警 的 各 个 
寄存 器 中 。 因 此 ， 这 里 的 BR 就 是 "BLT Register" 的 简写 ， 如 指令 
XY_COLOR_BLT 中 的 第 1 个 双 字 被 送 往 BLT3 引 擎 的 第 0 个 寄存 器 ， 第 2 个 双 


字 被 送 往 BLT 引 警 的 第 13 个 寄存 器 ， 等 等 。 


因此 ， 对 于 GPU 指令 来 说 ， 需 要 指明 自己 需要 哪个 微 核 来 处 理 ， 这 就 
是 第 一 个 双 字 中 第 29~31 位 的 作用 ，0x2 表 示 2D 指 令 、0x3 表 示 3D 指 令 等 。 
寄存 器 BR00 中 最 重要 的 就 是 指令 的 操作 码 ， 即 第 22~28 位 ， 对 于 指令 
XY_COLOR_BLT， 其 操作 码 是 0x50。 其 余 位 主要 用 于 控制 ， 如 第 11 位 用 于 


控制 是 否 打开 Tiling， 等 等 。 因 此 ， 寄 存 硕 BR00 也 被 称 为 "BLT Opcode& 


Control Register" ° 


根据 宏 XY_COLOR_BLT_CMD 的 定义 : 


xf86-video-intel-2.19.0/src/i830 reg.h: 


#define XY COLOR BLT CMD ((2<<29) | (0x50<<22) | (0x4)) 


其 中 从 第 22 位 开始 的 0x50 正 是 指令 XY_COLOR_BLT 的 指令 操作 码 。 第 
29~30 位 设置 为 2， 告 诉 GPU 这 个 指令 是 一 个 2D 指 令 ， 需 要 GPU 定 癌 给 BLT 


引擎 。 


2) 第 12 行 代码 填充 的 是 第 1 个 双 字 ， 对 应 BLT 引 警 的 寄存 器 BR13。 其 
中 "intel-> BR[13]" 是 为 了 方便 构建 指令 在 程序 中 定义 的 一 个 变量 ， 保 存 寄 
存 器 BR13 的 值 。 这 就 是 函数 uxa_poly_fill_rect 在 调用 solid 之 前 ， 调 用 函数 
prepare_solid 的 目的 。 在 UXA (uxa_ops) 中 ，prepare_solid 对 应 的 函数 是 


intel_uxa_prepare_solid: 


xf86-video-intel-2.19.0/src/intel uxa.c: 


static Bool intel uxa prepare solid(PixmapPtr pixmap, int alu, 
Pixel planemask, Pixel fg) 


{ 


switch (pixmap->drawable.bitsPerpixel) { 


case 8: 
break; 
case 16: 
/* RGB565 */ 


intel->BR[13] |= (1 << 24); 
break; 
CaSse 32;: 
/* RGB8888 */ 
intel=sBR[I13] | ((L sa 24) | (1 .< 25))3 


break; 
} 
intel->BR[16] = fg; 


return TRUE; 


} 


函数 intel _uxa_prepare_solid 根 据 图 像 实 际 使 用 的 色 深 ， 设 置 相应 的 位 。 
intel_uxa_prepare_solid 除 了 计算 了 寄存 絮 BR13 中 的 色 深 让 ， 也 计算 了 寄存 
器 BR16 的 值 ，BR16 中 的 值 是 GPU 进 行 填充 时 使 用 的 颜色 。 


除了 设置 色 深 外 ， 第 12 行 代码 也 设置 了 图 像 的 跨度 (pitch) ， 跨 度 是 
以 字 节 为 单位 表示 的 图 像 的 一 行 的 长 度 。 


3) 第 13 行 代码 填充 了 第 2 个 双 字 ， 对 应 BLT 引 擎 的 寄存 器 BR22， 这 个 
寄存 器 中 保存 的 是 目标 区 域 的 左上 角 的 坐标 。 


4) 第 14 行 代码 填充 了 第 3 个 双 字 ， 对 应 BLT3 引 警 的 寄存 器 BR23， 这 个 
寄存 器 中 保存 的 是 目标 区 域 的 右 下 角 的 坐标 。 


5) 第 15~16 行 代码 填充 的 第 4 个 双 字 ， 对 应 BLT 引 警 的 寄存 器 BR09， 这 
个 寄存 器 中 保存 的 是 目标 区 域 在 GPU 的 显存 空间 中 的 地 址 。 这 里 的 pixmap 
就 是 Screen Pixmap， 所 以 宏 OUT_RELOC_PIXMAP_FENCED 就 是 将 保存 前 
缓冲 的 像素 阵列 的 BO 在 显存 空间 中 的 地 址 填充 到 这 个 双 字 中 。 读 者 可 以 参 
见 前 面 关 于 宏 OUT_RELOC _PIXMAP_FENCED 的 介绍 。 


6) 第 17 行 代码 填充 了 第 5 个 双 字 ， 对 应 BLT 引 擎 的 寄存 器 BR16， 这 个 
寄存 器 中 保存 的 是 填充 使 用 的 颜色 。 


在 完成 指令 XY_COLOR_BLT 的 构建 后 ， 函 数 intel_batch_submit 将 用 户 
空间 的 batch_ptr 中 的 数据 复制 内 核 空 间 的 ， 并 通知 GPU ， 开 始 执行 批量 缓冲 
中 的 指令 ， 代 码 如 下 : 


xf86-video-intel-2.19.0/src/intel batchbuffer.c: 


void intel batch submit (ScrnIinfoptr scrn) 


{ 


ret = dri bo subdata(intel->batch bo, 0, intel->batch used*4, 
intel->batch ptr); 
if (ret == 0) { 
ret = drm intel bo mrb exec(intel->batch bo， 
intel->batch used*4, ...)); 


其 中 函数 dri_bo_subdata， 我 们 已 经 在 8.2.2 太 讨论 过 ， 其 负责 将 数据 从 
用 户 空 间 复 制 到 内 核 空间 。 所 以 这 里 就 是 2D 驱 动 将 组 织 在 用 户 空 间 中 的 数 
组 batch_ptr 中 的 数据 复制 到 批量 缓冲 在 内 核 中 对 应 的 BO 


函数 drm_intel bo_mrb_exec 通 知 GPU 开始 执行 批量 缓 冲 中 的 指令 。 方 式 
是 通过 写 GPU 的 一 个 寄存 右 ， 具 体 过 程 请 参考 8.4.2 季 。 


8.3.3 ”CPU 演 染 


根据 上 市 讨论 的 辑 数 uxa_poly_fill_rect， 我 们 看 到 ，GPU 并 不 是 接收 全 
部 的 绘制 实心 矩形 的 操作 。 对 于 不 满足 GPU 条 件 的 实心 矩形 ， 则 将 求助 于 
CPU 绘制 ， 对 应 的 函数 是 uxa_check_poly_fill_rect: 


xf86-video-intel-2.19.0/uxa/uxa-unaccel .c: 


void uxa check poly fill rect(...) 


{ 
if (uxa_prepare_access (PDrawable，UXA ACCESS RW)) { 


fbpolyFillRect (pDrawable, pGC, nrect, prect); 


BO 是 由 DRM 模 块 在 内 核 空间 分 配 的 ， 因 此 运行 在 用 户 空 间 的 X (2D 驱 
动 ) 要 想 访 问 这 个 内 存 ， 必 须 首 先 要 将 其 映射 到 用 户 空 间 ， 这 是 由 范 数 
uxa_prepare_access 来 完成 的 。 然 后 ，X 使 用 CPU 在 映射 到 用 户 空 间 的 BO 上 
进行 绘制 。 看 到 以 fb 开头 的 函数 fbPolyFillRect， 读 者 一 定 猜 到 了 ， 这 就 是 X 
的 全 层 的 函数 ， 而 人 b 层 正 是 软件 渲染 的 实现 。 


(1) 映 映 BO 到 用 户 空间 


落 数 uxa_check_poly_fill_rect 调 用 uxa_prepare_access 将 BO 映 冉 到 用 户 空 
则 : 


Xf86-video-intel-2.19.0/uxa/uxa.c: 


Bool uxa prepare access (DrawablePtr pDrawable, ...) 


{ 


if (uxa screen->info->prepare access) 
return (*uxa screen->info->prepare access) (pPixmap, 


return TRUE; 


在 UXA (uxa_ops) 中 ， 指 针 prepare_access 指 向 的 函数 是 


intel_uxa_prepare_access: 


xf86-video-intel-2.19.0/src/intel uxa.c: 


static Bool intel] uxa prepare access (PixmapPtr pixmap, 


{ 


struct intel pixmap *priv = 
dri bo *bo = priv->bo; 


ret = drm intel gem bo map gtt (bo); 


函数 intel _uxa_prepare_access 通 过 libdrm 库 中 的 函数 


wi 


intel get pixmap private (pixmap); 


drm_intel gem_bo_map_gtt 申 请 内 核 中 的 DRM 模 块 将 保存 前 缓冲 的 像素 阵列 


的 BO 了 映 映 到 用 户 空 间 : 


libdrm-2.4.35/intel/intel bufmgr gem.c : 


int drm intel gem bo map gtt (drm intel bo *bo) 


{ 


ret = map gtt (bo); 


} 


static int map gtt (drm intel bo *bo) 


{ 


bo gem->gtt virtual = mmap(0, bo->size, PROT READ | 
PROT WRITE, MAP SHARED, bufmgr gem->fd, ...); 


看 到 熟悉 的 函数 mmap， 读 者 应 该 一 切 都 明白 了 。 从 CPU 的 角度 看 ，BO 
与 普通 内 存 并 无 区 别 ， 所 以 ， 映 射 BO 与 映射 普通 内 存 完 全 相同 。 其 中 
bufmgr_gem->fd 指 向 的 就 是 代表 BO 的 共享 内 存 。 


(2) 使 用 CPU 在 映射 到 用 户 空 间 的 BO 上 进行 绘制 


我 们 再 来 简单 看 看 软件 泻 染 函数 fbPolyFillRect 的 实现 : 


Xxorg-server-1.12.2/fb/fbfillrect .c: 


VOid. fbPoLlyYF1LLReCt (+:) 


{ 


EDEL Li hs 
} 
xorg-server-1.12.2/fb/fbfill.c: 


OL EDELLL (Se) 


人 


switch (pGC->fillstyle) { 
case FillSolid: 


#ifndef FB ACCESS WRAPPER 


if (and || !pixman fill((uint32 t *) dst, dststride, dstBpp, 
partXl1 + dstXoff, partyYl + dstYoff, 
(PartX2: ~ DartXL)}, (partyz ~ DartyL)re Kon) 
#endif 
fiSoLid(, nn]? 
break; 


} 


xorg-server-1.12.2/fb/fbsolid.c: 


void fbsSolid'(;, .) 


{ 


WRITE(dst++, xor); 


} 


xorg-server-1.12.2/fb/fb.h: 


#define WRITE(ptr, val) (*(ptr) = (val)) 


根据 上 面 的 代码 可 见 ，X 的 软件 泻 染 层 ( 即 fb 这 一 层 ) ， 或 者 借助 库 
pixman 中 的 API， 或 者 目 己 直接 操作 像素 数组 ， 完 成 图 形 的 绘制 。 其 原理 非 
利和 滑 单 ， 吕 是 直接 设置 像素 数组 中 的 颜色 值 或 索引 。 


经 过 对 2D 泻 染 的 探讨 ， 我 们 看 到 ， 所 请 的 软件 渔 染 和 硬件 加 速 ， 本 质 
上 都 是 生成 图 像 的 像素 阵列 ， 只 不 过 一 个 是 由 CPU 来 计算 的 ， 男 外 一 个 是 
由 GPU 来 计算 的 。 当 然 ， 对 于 硬件 加 速 ，CPU 要 充当 一 个 翻译 ， 将 数学 模 
型 按照 GPU 的 要 求 翻 译 为 其 可 以 识别 的 指令 和 数据 。 


8.4 3D 演 染 


运行 在 X 上 的 2D 程 序 ， 都 将 绘制 请 求 发 给 X 服 务 器 ， 由 X 服 务 器 来 完成 
绘制 。 但 是 对 于 3D 图 形 的 绘制 ，X 应 用 需要 通过 套 接 字 向 X 服 务 器 传递 大 量 
的 数据 ， 这 种 机 制 严 重 影响 了 图 形 的 泻 染 效 率 。 为 了 解决 效率 问题 ，X 的 开 
发 者 们 设计 了 DRI 机 制 ， 即 X 应 用 不 再 将 绘制 图 形 的 请 求 发 送 给 X 服 务 右 
了 ， 而 是 由 应 用 目 行 绘制 。 


在 Linux 平 台 上 ，OpenGL 的 实现 是 Mesa， 所 以 在 本 节 中 ， 我 们 结合 
Mesa， 探 讨 3D 的 渲染 过 程 。 我 们 可 以 认为 Mesa 分 为 两 个 关键 部 分 : 


令 一 部 分 是 一 套 兼容 OpenGL 标 准 的 实现 ， 为 应 用 程序 提供 标准 的 
OpenGL API° 


令 男 外 一 部 分 是 DRI 驱 动 ， 通 常 也 被 称 为 3D 驱 动 ， 其 中 包括 Pipleline 的 
软件 实现 ， 也 就 是 说 ， 即 使 GPU 没有 任何 3D 计 算 能 力 ， 那 么 Mesa 也 完全 可 
以 使 用 CPU 完成 3D 浴 染 功 能 。3D 张 动 还 负 贡 将 3D 这 染 命令 翻译 为 GPU 可 以 
理解 并 能 执行 的 指令 。 不 同 的 GPU 有 各 自 的 “指令 集 *， 因 此 ， 在 Mesa 中 不 
同 的 GPU 都 有 各 自 的 3D 驱 动 。 


Pipeline 最 后 将 生成 好 的 像素 阵列 输出 到 帧 缓冲 ， 但 是 这 还 不 够 ， 因 为 
最 后 的 输出 需要 显示 到 屏幕 上 。 而 屏幕 的 显示 是 由 具体 的 窗口 系统 控制 
的 ， 因 此 ， 帧 缓冲 还 需要 与 具体 的 窗口 系统 相 结 合 。 但 是 X 的 核心 协议 并 不 
包含 OpenGL 相 关 的 协议 ， 因 此 ， 开 发 者 们 开发 了 GL 的 扩展 GLX (GL 


a Re 


Extension) 


持 DRI， 开 发 者 们 义 开 发 了 DRI 扩 展 。 显 然 ，GLX 以 及 


DRI 扩 展 在 X 和 Mesa 中 均 需 要 实现 。 


基本 上 ， 运 行 在 


X 和 窗口 系统 上 的 OpenGL 程 序 的 泻 染 过 程 ， 可 以 划分 为 


三 个 阶段 ， 如 图 8-6 所 示 。 
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图 8-6 


3D 演 染 架 


构图 


1) 应 用 创建 OpenGL 的 上 下 文 ， 包 括 向 X 服 务 器 申请 创建 帧 缓冲 。 应 用 
为 什么 不 自己 直接 向 内 核 的 DRM 模 块 请 求 创建 帧 缓冲 呢 ? 从 技术 上 讲 ， 应 
用 目 己 请 求 DRM 创 建 请 求 创建 帧 缓冲 没有 任何 问题 ， 但 是 为 了 将 帧 缓冲 与 
具体 的 窗口 系统 绑 定 ， 应 用 只 能 委屈 一 下 ， 放 低 姿 态 请 求 X 服 务 郁 为 其 创建 
帧 缓冲 。 这 样 ，Xx 服 务 右 束 掌 握 了 应 用 的 帧 绥 冲 的 一 手 材 料 ， 在 需要 时 ， 将 
帧 缓冲 显示 到 屏幕 。 帧 缓冲 是 应 用 程序 的 “画板 ”， 因 此 创建 完成 后 ，X 服 务 
器 需要 将 帧 缓冲 的 BO 的 信息 返回 给 应 用 。 


2) 应 用 程序 建立 数学 模型 ， 并 通过 OpenGL 的 API 将 数学 模型 的 数据 写 
入 顶点 缓冲 (vertex buffer) ; 更 新 GPU 的 状态 ， 如 指定 后 缓冲 ， 用 来 存储 
Pipeline 输 出 的 像素 阵列 ;然后 启动 Pipeline 进 行 演 染 。 


3) 演 染 完成 后 ， 应 用 程序 向 X 服 务 器 发 出 交换 (swap) 请 求 。 这 里 的 
交换 有 两 种 方式 ， 一 种 是 复制 (copy) ,所谓 复制 就 是 将 后 缓冲 中 的 内 容 
复制 到 前 缓 促 ， 这 是 由 GPU 中 BLT3 引 擎 负责 的 。 但 是 复制 的 效率 相对 较 低 ， 
所 以 ， 开 发 者 们 又 设计 了 一 种 称 为 页 翻转 (page flip) 的 模式 ， 在 这 种 模式 
下 ， 不 需要 复制 动作 ， 而 是 通过 GPU 的 显示 引擎 控制 显示 控制 右 扫 描 哪个 
帧 缓冲 ， 这 个 被 扫描 的 缓冲 此 时 扮演 前 缓冲 ， 而 另外 一 个 不 被 扫 摘 的 帧 组 
冲 则 作为 应 用 的 “画板 *?， 也 就 是 所 说 的 后 缓冲 。 


接 下 来 我 们 就 围绕 这 三 个 阶段 ， 讨 论 3D 程 序 的 泻 染 过 程 。 


8.4.1 创建 帧 缓冲 


在 2D 深 染 中 ， 演 染 过 程 都 由 X 服 务 夯 完成， 所 以 室 无 争议 ， 前 缓冲 由 
而 且 只 能 由 X 服 务 器 创建 。 但 是 对 于 DRI 程 序 来 说 ， 其 泻 染 是 在 应 用 中 完 
成 ， 应 用 当然 需要 知道 帧 缓冲 ， 但 是 X 服 务 器 控制 着 窗口 的 显示 ， 所 以 X 服 
务 器 也 需要 知道 帧 缓冲 。 所 以 ， 帧 缓 促 或 者 由 X 服 务 絮 创建 ， 然 后 告知 应 
用 ; 或 者 由 应 用 创建 ， 然 后 再 告知 X 服 务 右 。X 采 用 的 是 前 者 。 


虽然 OpenGL 中 的 帧 缓冲 的 概念 与 2D 相 比 有 些 不 同 ， 但 本 质 上 并 无 差 
别 ， 帧 绥 冲 中 的 每 个 缓冲 都 对 应 着 一 个 BO。 为 了 管理 方便 ，Mesa 为 帧 缓 促 
以 及 其 中 的 各 个 缓冲 分 别 抽象 了 相应 的 数据 结构 ， 代 码 如 下 : 


Mesa-8.0.3/src/mesa/main/mtypes.h: 


struct gl framebuffer 


{ 


struct gl renderbuffer attachment Attachment [BUFFER COUNT]; 


其 中 ， 结 构 体 gL_framebuffer 是 帧 缓冲 的 抽象 。 结 构 体 glL_renderbuffer 是 
颜色 缓冲 、 深 度 缓冲 等 的 抽象 。glL_framebuffer 中 的 数组 Attachment 中 保存 的 
就 是 颜色 缓冲 、 深 度 缓冲 等 。 


在 具体 的 3D 张 动 中 ， 通 常会 以 gl_renderbuffer 作 为 基 类 ， 派 生出 目 己 的 
类 。 如 对 于 Intel GPU 的 3D 张 动 ， 派 生 的 数据 结构 为 intel_renderbuffer: 


Mesa-8.0.3/src/mesa/drivers/dri/intel/intel fbo.h: 


struct intel renderbuffer 


struct swrast renderbuffer Base; 
struct intel mipmap tree *mt; /**< The renderbuffer storage. */ 


其 中 指针 mt 间接 指向 缓冲 区 对 应 的 BO 。 


如 同 在 Intel GPU 的 2D 张 动 中 ， 使 用 结构 体 intel_pixmap 封 装 了 BO 一 
样 ，Intel GPU 的 3D 张 动 也 在 BO 之 上 包装 了 一 层 intel_region。intel_region 中 
除了 包括 BO 外 ， 还 包括 缓冲 区 的 一 些 信息 ， 如 缓冲 区 的 宽度 、 高 度 等 : 


Mesa-8.0.3/src/mesa/drivers/dri/intel/intel regions.h: 
struct intel region 


{ 


drm intel bo *bo; /**< buffer manager's buffer */ 
GLuint refcount; /**< Reference count for region */ 
GLuint cpp; /**< bytes Per pixel */ 

GLuint width; /**< in pixels */ 


当 OpenGL 应 用 调用 gljXMakeCurrent 时 ， 束 开启 了 创建 帧 缓冲 的 过 程 ， 


这 个 过 程 可 分 为 三 个 阶段 : 


1) OpenGL 应 用 向 X 服 务 器 请 求 为 指定 窗口 创建 帧 缓冲 对 应 的 BO。 帧 
缓冲 中 包含 多 个 缓冲 ， 所 以 当然 是 创建 多 个 BO 了 。 


2) X 服 务 器 收 到 应 用 的 请 求 后 ， 为 各 个 缓冲 创建 BO。 在 创建 完成 后 ， 
将 BO 的 名 字 等 相关 信息 发 送 给 应 用 。 


3) 应 用 收 到 BO 信息 后 ， 将 更 新 GPU 的 状态 。 比 如 告诉 GPU 画板 在 哪 
里 。 


1. 应 用 请 求 X 服 务 絮 创建 BO 


帧 绥 神 与 具体 的 GPU 密切 相关 ， 因 此 创建 帧 缓冲 的 发 起 在 3D 张 动 中 。 
以 i915 系 列 的 3D 张 动 为 例 ， 发 起 创建 帧 缓冲 的 函数 为 intelCreateBuffer: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel screen.c: 
static GLboolean intelCreateBuffer(...) 
struct intel renderbuffer *rb; 
i gl1 framebuffer *fb = CALLOC STRUCT(g] framebuffer); 


rb = intel create renderbuffer (rgbFormat); 
_mesa add renderbuffer (fb, BUFFER FRONT LEFT, ...); 


画 数 intelCreateBuffer 先 后 创建 了 帧 缓冲 对 象 和 帧 缓冲 中 包含 的 各 
个 “ 子 " 缓 冲 对 象 ， 并 将 各 “于 ”缓冲 对 象 加 入 到 帧 缓冲 对 象 的 数组 Attachment 
中 。 但 是 并 不 是 OpenGL 中 规定 的 所 有 的 缓 神 对 象 都 需要 创建 ， 所 以 函数 
intelCreateBuffer 需 要 根据 具体 情况 创建 如 前 缓冲 、 后 缓冲 、 深 度 缓冲 等 对 
象 。 注 意 ， 这 里 所 谓 的 创建 缓冲 对 象 ， 仅 仅 是 搭建 起 了 一 个 空 架 子 而 已 ， 
帧 缓冲 尚未 与 具体 的 BO 绑 定 。 


一 旦 应 用 调用 glIXMakeCurrent 切 换 目 己 为 当前 应 用 ，gLXMakeCurrent 将 
调用 3D 驱 动 中 的 函数 intel_update_renderbuffers 请 求 X 服 务 絮 创建 指定 X 窗 口 
的 各 个 缓冲 区 的 BO: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel context.c: 


void intel update renderbuffers( DRIcontext *context, ...) 


{ 


if (try separate stencil) { 
intel query dri2 buffers with separate stencil (intel, 
drawable, &buffers, &attachments, &count); 
} else { 
intel query dri2 buffers no. separate. stencil(,,..); 


} 


其 中 ， 函 数 intel _query_dri2_buffers_with/no_separate_stencil 回 又 服务 右 
申请 为 ID 为 drawable 的 窗口 创建 帧 缓冲 。 以 


intel_query_dri2_buffers_with_separate_stencil 为 例 : 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel context.c: 


static void intel query dri2 buffers with separate stencil(,..) 


{ 
struct gl framebuffer *fb = drawable->driverPrivate; 


struct intel renderbuffer *front rb; 
struct intel renderbuffer *back rb; 


back rb = intel get renderbuffer(fb, BUFFER BACK LEFT); 


if (back rb) { 


(x*attachments) [i++] = _ DRI BUFFER BACK LEFT; 
(*attachments) [i++] = intel bits per pixel (back rb); 
*buffers = screen->dri2.loader->getBuffersWithFormat (drawable, 
.,， *attachments, ...); 


函数 intel _query_dri2_buffers_with_separate_stencil 将 帧 缓冲 中 的 各 个 组 
冲 组 织 为 一 个 数组 attachments， 其 格式 是 缓冲 的 ID 加 上 缓冲 的 色 深 ,后面 组 
织 X 请 求 将 使 用 这 个 数组 attachments。 然 后 调用 getBuffersWithFormat| 可 XX 服 


务 器 请 求 创 建 这 些 缓冲 的 BO。 在 Mesa 端 的 DRI 扩 展 中 ， 


getBuffersWithFormat 最 终 调 用 的 函数 是 DRI2GetBuffersWithFormat: 


Mesa-8.0.3/src/glx/dri2.c: 


DRI2Buffer * DRI2GetBuffersWithFormat (Display * dpy, XID drawable, 
.., Unsigned int *attachments, ...) 


GetRegqExtra (DRI2GetBuffers, count * (4 * 2), reqg); 
req->reqType = info->codes->major opcode; 
req->dri2ReqType = X DRI2GetBuffersWithFormat; 


req->drawable = drawable; 

req->count = count,; 

p= (CARD32 *) & reql[1]; 

£0r (1 = 0 1 ee (Count * 2Z}a jt+) 
p[i] = attachments [i]; 


if (! XReply(dpy, (xReply *) & rep, 0, xFalse)) { 

for (i = 0; i < rep.count; i++) { 
_XReadPad(dpy, (char *) &repBuffer, sizeof repBuffer); 
buffers[i] .attachment = repBuffer.attachment,; 
buffers[li] .name = repBuffer.name; 
buffers[i] .pitch = repBuffer.pitch,; 


buffers [i] .cpp = repBuffer.cpp; 
buffers[il] .flags = repBuffer .flags; 


函数 DRI2GetBuffersWithFormat 首 先 创建 一 个 
X_DRI2GetBuffersWithFormat 类 型 的 X 请 求 ， 根 据 前 面 组 织 的 数组 
attachments， 即 申请 创建 的 缓冲 的 信息 ， 组 织 X 请 求 的 消息 体 ， 消 息 体 中 包 
含 各 缓冲 的 ID 和 色 深 。 


然后 调用 Xlib 的 接口 _XReply 将 请 求 发送 给 X 服 务 器 ， 并 等 待 请 求 的 返 
回 bs) 


在 X 服 务 器 创建 BO 后 ， 会 将 BO 信息 返回 给 应 用 ，X 服 务 器 创建 BO 的 过 
程 我 们 下 节 讨 论 。 根 据 代码 我 们 看 到 ， 在 返回 的 BO 信息 中 最 关键 的 一 项 就 
是 BO 的 名 称 。 回 忆 8.2.2 节 的 讨论 ， 我 们 谈 到 无 论 是 X 服 务 器 还 是 应 用 ， 均 
使 用 名 称 访问 BO。 所 以 ， 这 里 返回 的 BO 的 名 称 就 是 为 了 使 DRI 应 用 通过 这 
个 名 称 访 问 BO。 看 到 名 称 ， 我 们 习惯 上 将 其 理解 为 字符 串 ， 实 际 上 在 内 核 
的 DRM 模 块 中 ， 为 BO 的 名 称 分 配 的 是 一 个 数字 。 


2.X 服 务 器 创建 BO 


XX 服务 器 中 处 理 OpenGL 应 用 为 帧 缓冲 创建 BO 请 求 的 范 数 是 
ProcDRI2GetBuffers WithFormat: 


Xorg-server-1.12.2/hw/xfree86/dri2/dri2ext.c: 


static int ProcDRI2GetBuffersWithFormat (ClientPptr client) 


{ 


attachments = (unsigned int *) g&stuff[1]; 
buffers = DRI2GetBuffersWithFormat (pDrawable, &width, &height, 
attachments, stuff->count, &count); 


return send buffers reply(client, pDrawable, buffers, ...); 


函数 ProcDRI2GetBuffersWithFormat 首 先 从 应 用 的 请 求 中 提取 
attachments， 然 后 调用 函数 DRI2GetBuffersWithFormat 创 建 BO， 最 后 通过 函 
数 send_buffers_reply 将 BO 的 信息 发 送 给 应 用 。 


函数 DRI2GetBuffersWithFormat 将 调用 函数 do_get_buffers 为 帧 缓冲 创建 
BO: 


xorg-server-1.12.2/hw/xfree86/dri2/dri2.c: 


static DRI2BPufferPtr * do get buffers(,.,) 
人 
as (i = 0; i < count; i++) { 
1 ee ne 
} 


函数 do_get_buffers 中 的 变量 count 为 应 用 请 求 创建 BO 的 数量 ， 显 然 ， 画 
数 do_get_buffers 是 在 循环 为 窗口 的 绥 冲 区 创建 BO。 其 中 
allocate_or_reuse_buffer 调 用 1830DRI2CreateBuffer 为 缓冲 区 创建 BO: 


xf86-video-intel-2.13.0/src/intel dri.c: 


01 static DRI2Buffer2Ptr I830DRI2CreateBuffer(DrawablePptr 


02 
03: { 
04 
05 
06 
07 
08 
09 
10 
11 
下 
让 
14 
15 
16 
hg 
18 } 


drawable, unsigned int attachment, ...) 


if (attachment == DRI2BufferFrontLeft) { 
pixmap = get front buffer(drawable),; 


} 


if (pixmap == NULL) { 
pixmap = screen->CreatePixmap(...); 
} 
i = pixmap flink (pixmap)) == 0) { 


在 前 面 讨论 2D 泻 染 时 ， 我 们 已 经 看 到 ，X 服 务 紫 局 动 时 ，2D 驱 动 在 初 
人 化 输出 设备 时 已 经 创建 了 前 缓冲 的 BO。 因 为 各 个 窗口 是 共享 这 个 前 缓冲 


的 ， 因 此 ， 如 果 DRI 应 用 申请 为 前 缓冲 创建 BO， 则 I830DRI2CreateBuffer 整 
不 必 创 建 了 ， 其 调用 函数 get_front_buffer 直 接 查 找 前 缓冲 的 BO， 如 代码 第 
5~8 行 所 示 。 


如 有 果 函 数 1830DRI2CreateBuffer 执 行 到 第 10 行 代码 时 ，pixmap 依 然 空 ， 
则 说 明 这 次 不 是 为 前 缓冲 创建 BO， 于 是 调用 函数 CreatePixmap 为 其 他 缓冲 
创建 BO。 在 UXA 中 ，CreatePixmap 指 同 函 数 intel_uxa_create_pixmap: 


xf86-video=intel=2.19,0/src/intel, UXa GE 


static PixmapPtr intel uxa create pixmap(...) 


{ 


priv->bo = drm intel bo alloc for render(...); 


函数 drm_intel bo_alloc for_render 是 库 libdrm 提 供 的 接口 ， 其 请 求 内 核 
的 DRM 模 块 为 缓冲 区 创建 BO。 


创建 好 BO 后 ， 本 数 I830DRI2CreateBuffer 使 用 库 libdrm 提 供 的 接口 
pixmap_flink， 请 求 内 核 的 DRM 模 块 为 BO 命名 ， 见 第 16 行 代码 。 


在 创建 完 缓冲 区 的 BO 后 ， 让 我 们 回 到 函数 
ProcDRI2GetBuffersWithFormat， 其 将 调用 send_buffers_reply 将 BO 的 相关 信 
息 发 送 给 应 用 程序 : 


Xxorg-server-1.12.2/hw/xfree86/dri2/dri2ext.c: 


static int send buffers reply(...) 


{ 


for (i = 0; i < count; i++) { 
XDRI2Buffer buffer; 


/* Do not send the real front buffer of a window to the client.*/ 


if ((pDrawable->type == DRAWABLE WINDOW) 
&& (buffers[i]->attachment == DRI2BufferFrontLeft)) { 
continue; 


} 


buffer.attachment = buffers[i]->attachment; 
buffer.name = buffers [i]->name; 


WriteToClient (client, sizeof (xDRI2Buffer), &buffer); 


} 


return Success; 


仔细 观察 send_buffers_reply， 可 见 ， 即 使 应 用 癌 X 服 务 器 发 出 了 索要 前 
缓冲 的 BO 的 申请 ，X 服 务 器 也 不 会 将 真正 的 前 缓冲 的 BO 的 信息 发 送 给 应 用 
程序 。 事 实 上 ， 对 于 运行 在 X 窗 口 系 统 上 的 OpenGL 应 用 来 说 ， 尽 管 应 用 程 
序 有 可 能 要 求 直 接 绘制 在 前 缓冲 上 ， 但 是 Xx 服务 器 发 给 OpenGL 应 用 的 只 是 
一 个 伪 前 缓冲 ， 和 普通 的 后 缓冲 没有 本 质 区 别 。 从 这 里 也 可 以 看 出 ，X 不 允 
许 DRI 应 用 不 通过 X 直 接 在 前 缓冲 上 绘制 ，X 不 希望 应 用 把 屏幕 显示 搞 乱 ， 

X 要 对 前 缓冲 有 绝对 的 控制 权 。 如 果 读 者 熟悉 Linux， 一 定 知道 第 1 版 的 
DRI， 在 开启 符合 管理 器 后 ， 运 行 DRI 应 用 时 ， 那 个 著名 的 glxgears 转 动 的 齿 
轮 不 受 复合 管理 器 管理 的 bug 。 


3. 更 新 GPU 状态 


系统 中 可 能 存在 多 个 OpenGL 程 序 并 行 运行 但 是 只 有 一 个 GPU 的 情况 。 
因此 ，GPU 要 分 时 给 不 同 的 OpenGL 程 序 使 用 。 如 同 进 程 切换 时 ，CPU 需 要 


切换 上 下 文 一 样 ， 在 对 不 同 的 OpenGL 程 序 进 行 泻 染 时 ，GPU 也 需要 在 不 同 
程序 之 间 切 换 。 


以 帧 缓冲 为 例 ， 每 个 OpenGL 程 序 都 有 自己 的 帧 缓冲 。 但 是 只 有 当前 进 
行 绘制 的 OpenGL 应 用 的 帧 缓冲 才 是 GPU 的 目标 帧 缓冲 。 因 此 ， 当 不 同 的 
OpenGL 程 序 进行 切换 时 ，GPU 需 要 切换 记录 帧 绥 促 地 址 的 寄存 嚣 ， 使 其 指 
向 当前 正在 进行 绘制 的 程序 的 帧 缓冲 。 


以 Intel i915 系 列 GPU 为 例 ， 在 其 3D 驱 动 中 ， 对 应 GPU 状 态 的 结构 体 为 


struct i915_ hw_state: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/i915 context.h: 


struct i915 hw state 
GLuint Ctx[I915 CTX SETUP SIZE]; 
GLuint Blend[I915 BLEND SETUP SIZE]; 
GLuint Buffer[I915 DEST SETUP SIZE]; 


struct intel region *draw region; 


, a 


结构 体 i915_hw_state 使 用 一 系列 的 数组 来 记录 GPU 的 状态 ， 其 中 指针 
draw_region 指 癌 的 束 是 人 存 输出 的 图 像 的 像素 阵 列 的 BO 。 


应 用 程序 从 X 服 务 器 获取 了 各 个 缓冲 区 的 BO 后 ， 需 要 更 新 GPU 中 帧 绥 
冲 相关 的 状态 。 以 i915 的 3D 张 动 中 缓冲 区 更 新 为 例 ， 更 新 GPU 的 帧 缓冲 状 
态 的 函数 是 i9 15_update_draw_buffer: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/i915 vtbl.c: 


static void i915 update draw buffer(struct intel context *intel) 


{ 


1 
2 
二 
4 struct intel renderbuffer *irb; 

5 irb = intel renderbuffer(fb-> ColorDrawBuffers[0]); 

6 colorRegion = (irb && irb->mt) ? irb->mt->region : NULL; 
8 
9 
1 


intel->vtbl.set draw region(intel, &colorRegion, ...); 


第 5 行 的 变量 itb 显 然 古 指 向 一 个 闫 色 绥 冲 区 。 


Intel GPU 的 3D 驱 动 中 采用 Mipmap 的 方式 保存 intel_region，Mipmap 是 
一 种 为 了 加 快 泻 染 速度 和 减少 图 像 锯齿 ， 将 贴图 处 理 成 由 一 系列 被 预先 计 
算 和 优化 过 的 图 片 的 技术 。 因 此 ， 第 6 行 代码 中 的 "irb- > mt- > region" 就 是 指 
向 封装 颜色 缓冲 BO 的 intel_region 对 象 。 


那么 _ColorDrawBnuffers 中 的 第 0 个 缓冲 指 辐 的 是 哪个 颜色 缓冲 呢 ? 看 看 
下 面 代码 片段 : 


Mesa-8.0.3/src/mesa/main/framebuffer.c: 


void mesa initialize window framebuffer(...) 


{ 


if (visual->doubleBufferMode) { 


fb->ColorDrawBuffer[0] = GL BACK.; 
fb-> ColorDrawBufferIindexes[0] = BUFFER BACK LEFT; 


根据 上 面 的 代码 片段 可 见 ， 这 个 颜色 缓冲 束 是 后 缓冲 。 


我 们 继续 看 函数 i915_update_draw_buffer 中 的 函数 set_draw_region， 对 
于 i915 的 3D 驱 动 ， 该 男 数 指针 指 癌 i915_set_draw_region: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/i915 vtbl.c: 


01 static void i915 set draw region(struct intel context *intel, 


02 struct intel region *color regions[], ...) 
03° 

04 “se 

05 struct i915 hw state *state = &i915->state; 

06 

07 intel region reference(&state->dqraw_ zegion， 

08 color regions [0] ) ; 

09 Fi 

Lo0 i915 set buf info for region( 

1 &state->Buffer{[I915 DESTREG CBUFADDRO], 
12 color regions[0], BUF 3D ID COLOR BACK); 
3 “4 

14 I915 STATECHANGE (i915, I915 UPLOAD BUFFERS); 

15 } 

16 

17 Mesa-8.0.3/src/mesa/drivers/dri/i915/i915 context.h: 
18 


19 #define I915 DESTREG CBUFADDRO 0 


其 中 ， 第 7~8 行 代码 中 调用 的 函数 intel_region_reference 比 较 简 单 ， 就 是 
将 i915_hw_state 中 的 draw_region 设 置 为 color_regions[0]， 其 就 是 我 们 刚刚 在 
函数 i915_update_draw_buffer 中 讨论 的 后 缓冲 。 


在 考察 第 10~12 行 代码 调用 的 函数 i915_set_buf_info_for_region 前 ， 先 来 
看 一 下 传 给 这 个 函数 的 3 个 参数 。 根 据 第 19 行 的 宏 定义 ， 可 见 第 1 个 参数 就 
是 i915_hw_state 中 数组 Buffer 的 首 地 址 ; 第 2 个 参数 color_regions[0] 是 后 组 
冲 ; 第 3 个 参数 从 名 字 上 可 以 猜 出 大 概 是 GPU 用 来 标识 后 缓冲 的 ID。 了 解 了 
参数 后 ， 我 们 来 看 一 下 这 个 函数 的 具体 代码 : 


Mesa-8.0.3/src/mesa/drivers/dri/i915/i915 vtbl.c: 


void i915 set buf info for region(uint32 t *state, 
struct intel region *region, uint32 t buffer id) 


state[0] = 3DSTATE BUF INFO CMD; 
State[1] = buffer id; 
} 
显然 ， 函 数 i915_set_buf_ info_for_region 职 是 设置 1915_hw_state 中 数组 


Buffer 的 前 两 个 元 素 的 值 。 第 一 个 元 素 被 赋值 为 GPU 指令 
_3DSTATE_BUF_INFO_CMD; 第 二 个 元 素 被 赋值 为 标识 后 缓冲 的 ID 。 


更 新 了 i915_hw_state 中 的 状态 信息 后 ， 函 数 i915_set_draw_region 调 用 
I915_STATECHANGE 将 状态 信息 组 织 到 批量 缓冲 。GPU 将 在 进行 绘制 之 

， 从 批量 缓冲 中 读 取 这 些 信息 ， 并 更 新 自身 的 状态 。 
I915_STATECHANGE 最 终 调 用 函数 i915_emit_state 组 织 批量 缓冲 : 


Mesa-8.0.3/src/mesa/drivers/dri/i915/i915 vtbl.c: 


01 static void i915 emit state(struct intel context *intel) 


O02 “{ 

03 Ws 

04 BEGIN BATCH (count); 

05 OUT BATCH (state->Buffer[I915 DESTREG CBUFADDRO]); 
06 OUT BATCH (state->Buffer[I915 DESTREG CBUFADDR]1]); 
07 if (state->draw region) { 

08 OUT RELOC(state->draw_ region->bo, 

09 I915 GEM DOMAIN RENDER, I915 GEM DOMAIN RENDER, 0); 
10 } else { 

1 六 

Tl 

13 

14 Mesa-8.0.3/src/mesa/drivers/dri/intel/intel reg.h: 

15 


16 #define 3DSTATE BUF INFO CMD (CMD 3D| (0xld<<24) | (0x8e<<16) |1) 
17 /*% DWord 1 Ww 


18 #define BUF 3D ID COLOR BACK (0x3<<24) 

19 #define BUF 3D ID DEPTH (0x7<<24) 
PN 

2 

22 #define BUF_ 3D ADDR (x) ((x) & ~0x3) 


根据 第 5~6 行 代码 ， 批 量 绥 冲 中 的 前 两 个 元 素 分 别 为 915_hw_state 中 
Buffer 数 组 中 的 第 一 个 和 第 二 个 元 素 。 我 们 刚刚 讨论 过 ， 这 两 个 元 素 分 别 是 
GPU 指令 3DSTATE _BUF_INFO_CMD 和 GPU 用 来 标识 后 缓冲 的 ID 的 。 


笔者 没有 找到 有 关 GPU 指 令 3DSTATE _BUF INFO_CMD 的 参考 ， 但 是 
根据 上 面 代码 第 16~22 行 的 宏 定义 ， 我 们 可 以 猜 出 一 二 : 
1) _3DSTATE_BUF_INFO_CMD 是 个 指令 ID， 应 该 是 告诉 GPU 更 新 相 


天 缓冲 的 信息 。 


2) 在 指令 码 之 后 ， 紧 接 的 第 一 个 参数 中 至 少 应 该 包含 要 更 新 的 缓冲 区 
的 ID， 这 里 BUF_3D_ID_COLOR BACK 应 该 是 GPU 内 部 用 来 标识 后 缓冲 的 


ID 。 我 们 看 到 这 个 ID 大 约 占据 从 24 位 开始 的 几 位 ， 如 011 对 应 的 是 后 缓冲 ， 
111 对 应 的 是 深度 缓冲 。 


3) 既然 通知 GPU 更 新 后 缓冲 的 地 址 ， 当 然 需要 将 后 缓冲 所 在 的 BO 告 
知 GPU 了 “。 所 以 指令 码 之 后 的 第 二 个 参数 应 该 是 更 新 的 缓冲 的 BO。 当 然 
了 ， 这 里 要 使 用 BO 在 GPU 地 址 空间 的 地 址 。 上面 代 码 第 8~9 行 的 安 正 是 在 
批量 缓冲 中 写 入 了 后 缓冲 BO 的 地 址 。 


事实 上 ， 除 了 更 新 了 GPU 中 后 缓冲 的 信息 外 ， 也 更 新 了 GPU 的 其 他 状 
态 ， 这 里 不 再 一 一 讨论 。 


8.4.2” 泻 染 Pipleline 


与 2D 泻 染 相 比 ，3D 泻 染 要 复杂 得 多 。 束 如 同 有 些 复 洒 的 绘画 过 程 ， 要 
分 成 几 个 阶段 一 样 ，OpenGL 标 准 也 将 3D 的 演 染 过 程 划 分 为 一 些 阶段 ， 并 将 
由 这 些 阶段 组 成 的 这 一 过 程 形 象 地 称 为 Pipleline。 


应 用 程序 建立 基本 的 模型 包括 在 对 象 坐标 中 的 顶点 数据 、 顶 点 的 各 种 
属性 〈 比 如 颜色 ) ， 以 及 如 何 连 接 这 些 顶 点 (如 是 连接 成 直线 还 是 连接 为 
三 角形 ) ， 等 等 ， 统 一 存储 在 顶点 缓冲 中 ， 然 后 作为 Pipeline 的 输入 ， 这 些 
输入 就 像 原 材料 一 样 ， 经 过 Pipeline 这 台 机 器 的 加 工 ， 最 终生 成 像素 阵列 ， 
输出 到 后 缓冲 的 BO 中 。 


OpenGL 的 标准 规定 了 一 个 参考 的 Pipeline， 但 是 各 家 GPU 的 实现 与 这 个 
参考 还 是 有 很 多 差别 的 ， 有 的 GPU 将 相应 的 阶段 合并 ， 有 的 GPU 将 个 别 阶 
段 又 拆 分 了 ， 有 的 可 能 增加 了 一 些 阶段 ， 有 的 又 砍 了 一 些 阶段 。 但 是 ， 大 
体 上 整个 过 程 如 图 8-7 所 示 。 
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Stencil buffer 


Depth buffer 


Color buffer 


Framebuffer : 


OpenGL 使 用 顶点 的 集合 来 定义 或 远近 对 象 ， 应 用 程序 建 模 实际 上 束 是 
组 织 这 些 顶 点 ， 当 然 也 包括 顶点 的 属性 。Pipeline 的 第 一 个 阶段 束 是 顶点 处 
理 (vertex operations) ， 顶 点 处 理 单元 将 几何 对 象 的 顶点 从 对 象 坐标 系 变 
换 到 视点 坐标 系 ， 也 束 古 将 三 维 空间 的 侍 标 投影 到 二 维 坐 标 ， 并 为 每 个 顶 
扩 赋 颜色 值 ， 并 进行 光照 处 理 等 。 


(2) 图 元 装配 


显 然 ， 很 多 操作 处 理 是 不 能 以 顶点 单独 进行 处 理 的 ， 比 如 裁减 、 光 机 
化 等 ， 需 要 将 顶点 组 装 成 几何 图 形 。Pipeline 将 处 理 过 的 顶点 连接 成 为 一 些 
最 基本 的 图 元 ， 包 括 点 、 线 和 三 角形 等 。 这 个 过 程 成 为 图 元 装配 (primitive 


assembly) 。 


任何 一 个 曲面 都 是 多 个 平面 无 限 帝 近 的 ， 而 最 基本 的 是 三 点 表示 一 个 
平面 。 所 以 ， 理 论 上 ，GPU 将 曲面 都 划分 为 才干 个 三 角形 ， 也 束 是 使 用 三 
角形 进行 装配 。 但 是 也 不 排除 现代 GPU 的 设计 者 们 使 用 其 他 的 更 有 效 的 图 
元 ， 比 如 梯形 ， 进 行 装配 。 


(3) 光栅 化 


我 们 前 文 提 到 ， 图 形 是 使 用 像素 阵列 来 表示 的 。 所 以 ， 图 元 最 终 要 转 
化 为 像素 阵列 ， 这 个 过 程 称 为 光栅 化 (rasterization) ， 我 们 可 以 把 光 棚 理 
解 为 像素 的 阵列 。 经 过 光栅 化 之 后 ， 图 元 被 分 解 为 一 些 片断 fragment) ， 
每 个 片段 对 应 一 个 像素 ， 其 中 有 位 置 值 (像素 位 置 ) 、 颜 色 、 纹 理 坐 标 和 


深度 等 属性 。 


(4) 片段 处 理 


在 Pipeline 更 新 帧 缓冲 之 前 ，Pipeline 执 行 最 后 一 系列 的 针对 每 个 片段 的 
操作 。 对 于 每 一 个 片断 ， 首 先进 行 相关 的 测试 ， 比 如 深度 测试 、 模 板 测 
试 。 以 深度 测试 为 例 ， 只 有 当 片 段 的 深度 值 小 于 深度 缓存 中 与 片段 相对 应 
的 像素 的 深度 值 时 ， 颜 色 缓 冲 、 深 度 缓冲 中 的 与 片段 相对 应 的 像素 的 值 才 
会 被 这 个 片段 中 对 应 的 信息 更 新 。 


Pipeline 可 全 部 由 软件 实现 (CPU) ， 也 可 全 部 由 硬件 实现 (GPU) ， 
或 者 二 者 混合 ， 这 完全 取决 于 GPU 的 能 力 。 对 于 GPU 没有 3D 计 算 能 力 的 ， 
则 Pipeline 完 全 由 软件 实现 。 比 如 ，Mesa 中 的 _tnl_default_pipeline， 即 是 一 
个 纯 软 件 的 Pipeline，Pipeline 中 的 每 一 个 阶段 均 由 CPU 负责 洽 染 ; 


Mesa-8.0.3/src/mesa/tnl/t pipeline.c: 


const struct tnl pipeline stage * tnl default pipeline[] = { 
& tnl vertex transform stage, 
& tnl normal transform stage, 
& tnl lighting stage, 
& tnl texgen stage, 


& tnl texture transform stage, 
& tnl point attenuation stage, 
& tnl] vertex program Stage， 

& tnl fog coordinate stage, 

& tnl render stage, 

NULL 


}; 


对 于 3D 计 算 能 力 比 较 强 的 GPU， 如 ATI 的 GPU，Pipeline 完 全 由 GPU 实 
现 。 


而 有 些 GPU 能 力 不 那 么 强大 ， 那 么 CPU 就 要 参与 图 形 泻 染 了 ， 因 此 ， 
Pipeline 一 部 分 由 CPU 实现 ， 一 部 分 由 GPU 实现 ， 比 如 基于 Intel i915 GPU 的 


Pipeline: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel render.c: 


const struct tnl pipeline stage *intel pipeline[] = { 
& tnl vertex transform stage, 
& tnl normal transform stage， 
& tnl] lighting stage, 
& tnl fog coordinate stage, 
& 七 五 上 texgen stage; 
& tnl texture transform stage, 
& tnl point attenuation stage, 
& tnl] vertex program stage, 
#1 和 E 是 
& intel render stage, 
#endif 
& tnl render stage, 
0, 


js 


相 比 于 _tnl_default_pipeline，intel_pipeline 使 用 _intel _render_stage 替 换 


了 _tnl_render_stage。 


以 Intel GPU 为 例 ，Pipeline 的 泻 染 过 程 大 致 如 网 8-8 所 示 。 
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Frame Buffer 


应 用 程序 通过 glVertex 等 OpenGL API 将 数据 写 入 用 户 空间 的 


2) 当 程 序 显 示 调 用 glFlush， 或 者 ， 当 顶点 缓冲 满 时 ， 其 将 自动 激活 
glFlush，glFlush 将 启动 Pipeline。 以 intel_pipeline 为 例 ，Pipeline 的 前 几 个 阶 
段 是 CPU 负责 的 ， 因 此 ， 所 有 的 输入 来 自用 户 空间 的 顶点 缓冲 ， 计 算 结果 
也 输出 到 用 户 空间 的 顶点 缓冲 ; 在 最 后 的 _intel_render_stage 阶 段 ， 按 照 intel 
GPU 的 要 求 ， 从 公共 的 顶点 缓冲 中 读 取 数据 ， 使 用 intel GPU 的 3D 驱 动 中 提 
供 的 函数 ， 重 新 组 织 一 个 符合 intel GPU 规范 的 顶点 缓冲 。 


3) glFlush 调 用 3D 驱 动 中 的 函数 intel_glFlush。intel_glFlush 首 先 将 顶点 
缓冲 和 批量 缓冲 复制 到 内 核 空 间 对 应 的 BO， 实 际 上 束 是 相当 于 复制 到 了 


GPU 的 显存 空间 ， 这 样 GPU 束 可 以 访问 了 了。 然后 ， 内 核 的 DRM 模 块 将 按照 
Intel GPU 的 要 求 建立 一 个 环形 缓冲 区 (ring buffer) 。 


4) 准备 好 环形 缓冲 区 后 ， 内 核 中 的 DRM 模 块 将 环形 缓冲 区 的 信息 ， 如 
缓冲 区 的 头 和 尾 的 地 址 分 别 写 入 GPU 的 寄存 器 Head Offset 和 Tail Offset 等 。 
当 DRM 同 寄存 侣 Tail Offset 写 入 数据 时 ， 将 触发 GPU 读 取 并 执行 环形 缓冲 区 
中 的 命令 ， 局 动 GPU 中 的 Pipeline 进 行 泻 染 。 最 后 ，GPU 的 Pipepline 将 生成 
的 像素 阵列 输入 到 帧 缓冲 。 


1. 建 立 数学 模型 


使 用 OpenGL 绘 制 ， 首 先 需 要 将 绘制 的 内 容 使 用 数学 模型 描述 出 来 ， 
个 描述 的 过 程 的 最 终结 果 将 保存 在 顶点 绥 冲 中 。 我 们 以 函数 glVertex3f 为 
例 ， 来 简单 看 看 这 个 过 程 。 


因为 可 能 存在 多 个 上 下 文 ， 比 如 某 个 上 下 文 使 用 的 是 软件 演 染 ， 另 外 
一 个 上 下 文 使 用 的 是 硬件 泻 染 ， 因 此 ，Mesa 采 用 分 发 函数 表 (dispatch 
table) 实现 访问 当前 上 下 文 的 GL 函 数 。 


GL 上 下 文中 有 一 个 指 癌 结 构 体 _glapi_table 的 指针 Exec， 用 于 指 问 当前 
上 下 文 的 分 发 男 数 表 ， 具 体 代 人 码 如 下 : 


Mesa-8.0.3/src/mesa/main/mtypes.h: 


struct gl context 


{ 


struct glapi table *Exec; /**< Execute functions */ 


函数 表 作为 GL 上 下 文 的 一 部 分 ， 在 创建 上 下 文 时 进行 初始 化 ， 有 具体 代 
码 如 下 : 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel context.c: 


bool TntelInitcContextily ns} 


if (! mesa initialize context(...) { 


_Vbo CreateContext (ctx); 


其 中 ， 函 数 _mesa_initialize_context 创 建 了 函数 表 ， 并 初始 化 函数 表 
中 的 部 分 GL 画 数 ， 如 glFlush。 函 数 glVertex3f 是 在 初始 化 VBO 时 初始 化 的 : 


攻 | 


Mesa-8.0.3/src/mesa/vbo/vbo exec.c: 


VOld Vbo exec jinieE( struet gl Context. *etx ,) 


vbo exec vtx init( exec ); 
Mesa-8.0.3/src/mesa/vbo/vbo exec api.c: 


void vbo exec vtx init( struct vbo exec context *exec ) 


vbo_ exec vtxfmt init( exec ); 
_mesa install exec vtxfmt( ctx, &exec->vtxfmt ); 


} 


static void vbo exec vtxfmt init!( struct vbo exec context *exec ) 


{ 


vfmt->Vertex3f = vbo Vertex3f; 


在 函数 vbo_exec_vtxfmt_init 中 ， 函 数 指针 Vertex3f 指 同 的 画 数 最 后 会 被 
mesa_install_exec_vtxfmt 安 装 到 函数 表 中 ， 对 应 函数 glVertex3f 。 


我 们 先 来 看 看 函数 vbo_Vertex3f 的 实现 : 


Mesa-8.0.3/src/mesa/vbo/vbo exec api.c: 
#define TAG(x) vbo ##x 

#include "vbo attrib tmp.h" 
Mesa-8.0.3/src/mesa/vbo/vbo attrib tmp.h: 


static void GLAPIENTRY TAG (Vertex3f) (GLfloat x, GLfloat y, 
GLfloat z) 


GET CURRENT CONTEXT (ctx) ; 
ATTR3F (VBO_RTTRIB POS, x, y, 2); 


根据 宏 TAG 的 定义 ， 显 然 ，TAG(Vertex3f) 就 是 vbo_Vertex3f 的 函数 实 
现 。 其 中 宏 ATTR3F 的 定义 如 下 : 


Mesa-8.0.3/src/mesa/vbo/vbo attrib tmp.h: 


#define ATTR3F( A, X, Y, 2 ) NTTR(. 2 Br Wi Ty i 1 


Mesa-8.0.3/src/mesa/vbo/vbo exec api.c: 


#define ATTR( A, N, VO, V1, V2, V3 ) 
do { 
struct vbo exec context *exec = &Vvbo context (ctx) ->exec; 


GLfloat *dest = exec->vtx.attrptr [A]; 


A a a ee 


if (N>0) dest [0] = VO; 
aE (NSL) dest [ET]) Bl ML 
if (N>2) dest [2] = V2; 
if (N>3) dest [3] = V3; 
} 
} while (0) 


根据 宏 ATTR 的 定义 可 见 ，vbo_Vertex3f 就 是 将 数学 模型 的 相关 数据 写 
入 顶点 缓冲 。 


了 解 了 函数 vbo_Vertex3f 的 实现 后 ， 我 们 看 看 _mesa_install_exec_vtxfmt 
是 如 何 将 其 安装 到 函数 表 的 : 


Mesa-8.0.3/src/mesa/main/vtxfmt.c: 


void mesa install exec vtxfmt (struct gl context *ctx, 
const GLvertexformat *vfmt) 


{ 
if (ctx=SAPI == API OPENGL) 
install] vtxfmt( ctx->Exec, vfmt ); 
} 


static void install vtxfmt( struct glapi table *tab, 
const GLvertexformat *vfmt ) 


SET Vertex3f (tab, vfmt->Vertex3f); 


函数 SET_Vertex3f 的 相关 代码 如 下 : 


Mesa-8.0.3/src/mesa/main/dispatch.h: 


static inline void SET Vertex3f (struct glapi table *disp, 


void (GLAPIENTRYP fn) (GLfloat, GLfloat, GLfloat)) { 
SET by offset(disp, gloffset Vertex3f, fn); 


} 

#define gloffset Vertex3f 136 

#define SET by offset (disp, offset, fn) \ 
do { 


ev 
({ glapi proc *) (disp)} Lofftset] = ( dlapi proc) fn; \ 


为 宏 _gloffset_Vertex3f 的 定义 为 136， 所 以 宏 SET_by_offset 设 置 函数 
表 中 第 136 项 的 函数 指针 指向 函数 vbo_Vertex3f。 我 们 来 看 看 GL 函数 表 中 的 
第 136 项 的 函数 指针 : 


Mesa-8.0.3/src/mapi/glapi/glapitable.h: 


struct glapi table 


{ 


void (GLAPIENTRYP Vertex3f) (GLfloat x, GLfloat y, GLfloat 2z); 
YY L9G6 Ty 


我 们 看 到 函数 表 中 的 第 136 项 是 Vertex3f， 而 不 是 glVertex3f， 是 不 是 很 
困惑 ? 


事实 上 ， 由 于 采用 这 种 跳 转 函数 表 的 方式 ， 给 GL 函数 调用 市 来 许多 不 
必要 的 开销 ， 因 此 ，Mesa 进 行 了 必要 的 优化 。 比如， 在 IA32 平 台 上 ，Mesa 
使 用 汇编 语言 实现 OpenGL API 规 定 的 这 些 画 数 。 相 比 使 用 C 语 言 ， 使 用 汇 
编 语 言 实现 的 函数 编译 后 的 机 器 指令 要 更 精简 一 些 ， 相 关 代 码 如 下 : 


Mesa-8.0.3/src/mapi/glapi/glapi x86.3: 


01 GLNAME (gl dispatch functions start): 
02 Ee 
03 GL STUB (Vertex3f, 136, Vertex3f@12) 


06 # define GL STUB (fn,off,fn alt) x 
07 GL PREFIX(fn, fn alt): \ 
08 yr 六 
号 A CALL( x86 get dispatch) :; \ 
10 JMP (GL OFFSET (off) ) 

下 


12 # define GL PREFIX(n,n2) GLNAME (CONCAT (g1,D) ) 


因为 要 处 理 多 种 情况 ， 再 加 上 一 些 人 额外 的 汇编 伪 指 令 ， 所 以 代码 比较 
复 洒 ,为 了 增加 可 读 性 ， 笔 者 进行 了 必要 的 删 减 。 


从 第 1 行 代码 处 开始 ，Mesa 使 用 宏 GL_STUB 开 始 定 义 OpenGL API 规 定 
的 函数 ， 其 中 第 3 行 代码 定义 的 束 是 函数 glVertex3f 。 


注意 定义 函数 使 用 的 宏 GL_STUB， 其 在 第 6~10 行 代码 定义 。 其 中 第 7 
行 代码 定义 的 是 函数 名 ， 代 码 中 宏 GL_PREFIX 在 第 12 行 代码 定义 ， 就 是 给 
函数 名 称 前 加 个 前 缀 gl， 所 以 


GL PREFIX(Vertex3f, Vertex3f@12) 


展开 后 为 ; 


glVertex3f 


可 见 ， 第 3 行 代码 使 用 宏 GL_STUB 定 义 的 就 是 函数 glVertex3f 。 


我 们 再 来 看 看 安 GL_STUB 定 义 的 函数 体 。 第 9 行 代码 获取 画 数 表 所 在 
的 基 址 ， 然 后 跳 转 到 偏 移 off 处 ， 见 第 10 行 代码 。 以 函数 glVertex3f 为 例 ， 根 
据 第 3 行 代码 可 见 ， 这 个 偏 移 是 136。 也 就 是 说 ， 当 程序 执行 函数 glLVertex3f 
时 ， 其 将 跳 转 到 函数 表 中 第 136 项 指针 指 辣 的 函数 。 


而 前 面 画 数 SET_Vertex3f 正 是 将 函数 vbo_Vertex3f 安 装 到 了 函数 表 的 第 
136 项 。 也 就 是 说 ， 当 执行 函数 glVertex3f 时 ， 实 际 跳 转 到 的 函数 就 是 


vbo_Vertex3f ° 


2. 启 动 Pipeline 


在 建 模 后 ， 应 用 将 顶点 数据 存 入 了 顶点 缓冲 ， 加 工 需 要 的 原材料 已 经 
准备 好 了 ， 接 a a 。 那么 ， 这 个 机 器 什 
么 时 候 运 转 起 来 呢 ? 通常 是 在 程序 中 显示 调用 函数 glFlush 时 。 当 然 ， 一旦 
顶点 缓冲 已 经 充满 了 ， 也 会 自动 调用 glFlush。 读 者 可 能 有 个 疑问 ， 我 们 编 
写 程序 时 ， 有 时 并 没有 显示 调用 glFlush 啊 ?” 没 错 ， 那 是 通常 情况 下 ， 我 们 
使 用 的 都 是 启用 了 双 缓 冲 的 OpenGL ， 即 前 缓冲 和 后 缓冲 。 对 于 启用 双 缓 冲 
的 OpenGL 程 序 ，OpenGL 规 定 ， 当 程序 在 后 缓冲 泻 染 完成 后 ， 请 求 交 换 到 
前 后 缓冲 时 ， 使 用 OpenGL 的 API glIXSwapBuffers， 而 实际 上 ， 画 数 
glXSwapBuffers 已 经 荐 我 们 调用 了 glFlush 。 


当 调 用 函数 glFlush 时 ， 将 通过 函数 表 跳 转 到 画 数 _mesa_flush: 


Mesa-8.0.3/src/mesa/main/context.c: 


void mesa flush(struct gl context *ctx) 


{ 


FLUSH CURRENT( ctx, 0 ); 
if (ctx->Driver.Flush) f 
ctx->Driver.Flush (ctx); 


函数 mesa_flush 首 先 使 用 宏 FLUSH_CURRENT 启 动 CPU 负责 的 
Pipeline。 在 CPU 负责 的 Pipeline 运 行 完 毕 后 ，_mesa_flush 调 用 驱动 中 的 Flush 
函数 将 用 户 空 间 的 顶点 缓冲 、 批 量 缓冲 的 数据 复制 到 内 核 空 间 ， 并 启动 
GPU 中 的 Pipeline 。 


宏 FLUSH_CURRENT 调 用 画 数 _tnl_draw_prims 开 动 Pipeline， 具 体 代 码 
如 下 : 


Mesa-8.0.3/src/mesa/tnl/t draw.c: 


Gd tnl, draw ES) 


fe (i = 0F tt < TE palmss) 
for (inst = 0; inst < priml[li] .num instances; inst++) { 


TNL CONTEXT (ctx) ->Driver.RunPipeline (ctx); 


我 们 看 到 ， 对 于 每 个 绘制 原 语 ， 函 数 _tnl_draw_prims 分 别 启动 Pipeline 
对 其 进行 加 工 。 对 于 Intel GPU 的 3D 驱 动 ，RunPipeline 指 向 的 函数 是 


intelRunPipeline: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel tris.c: 


static void intelRunPipeline (Stzuct gl] context * ctx) 


{ 
_tnl run pipeline (ctx); 


Mesa-8.0.3/src/mesa/tnl/t pipeline.c: 


void tnl Fun pipeline( struct gl context *ctx ) 


{ 


for (i = 0; i < tnl->pipeline.nr stages ; i++) { 


struct tnl pipeline stage *s = &tnl->pipeline.stages [i]; 
了 (ED tx; DB 计 


break; 


函数 _tnl_run_pipeline 依 次 运行 Pipeline 中 每 个 阶段 的 run 函 数 ， 一 旦 某 个 


阶段 的 函数 run 返 回 False， 则 表明 整个 Pipeline 运 行 结束 。 
3.Pipeline 中 的 软件 计算 阶段 


所 谓 的 软件 计算 阶段 ， 是 指 计算 过 程 定 由 CPU 来 负责 的 。CPU 从 上 下 
文中 获取 上 个 阶段 的 状态 信息 ， 进 行 计算 ， 然 后 将 计算 结果 保存 到 上 下 文 
中 ， 作 为 下 一 个 阶段 的 输入 。 上 下 文 的 数据 抽象 为 结构 体 TNLcontext， 其 
中 非常 重要 的 一 个 成 员 古 结构 体 vertex_buffer: 


Mesa-8.0.3/src/mesa/tnl/t context.h: 


typedef struct 


{ 


struct vertex buffer vb; 


} TNLcontext ; 


顾名思义 ， 结 构 体 vertex_buffer 是 保存 顶点 数据 的 。 软 件 计 算 阶 段 的 所 
有 顶点 数据 来 自 这 个 vertex_buffer， 经 过 变换 后 的 顶点 数据 也 输出 到 这 个 


vertex_buffer 中 。 


以 intel_pipeline 中 的 texgen 阶 段 为 例 : 


Mesa-8.0.3/src/mesa/tnl/t vb vertex.c: 


01 static GLboolean run texgen stage(l struct gl context *ctx, 
02 struct tnl pipeline stage *stage ) 


04 struct vertex buffer *VB = &TNL CONTEXT (ctx) ->Vb:; 
05 struct texgen stage data *store = TEXGEN stage DATA (stage); 


07 for (i = 0 ; i < ctx->Const.MaxTextureCoordUnits ; i++) { 
09 store->TexgenFunc[i]( ctx, store, i );， 


a VB->AttribPtr [VERT ATTRIB TEXO + 3] = 
下 2 &store->texcoord[il]; 


第 9 行 代码 计算 纹理 的 坐标 ， 并 将 结果 保存 到 store 的 数组 texcoord 中 。 
而 在 函数 TexgenFunc 的 计算 过 程 中 ， 使 用 了 来 和 目 TNLcontext 中 的 结构 体 
vertex_buffer 中 的 各 种 状态 信息 。 


计算 完成 后 ， 函 数 rn_texgen_stage 也 将 这 个 阶段 的 计算 结果 保存 到 了 
TNLcontext 中 的 结构 体 vertex_buffer 中 ， 如 代码 第 11~12 行 所 示 。 


4.Pipeline 中 GPU 相关 的 阶段 


很 难 要 求 所 有 三 家 的 GPU 都 按照 一 个 标准 设计 ， 所 以 在 局 动 GPU 中 的 
硬件 阶段 之 前 ， 需 要 将 OpenGL 标 准 规定 的 标准 格式 的 顶点 缓冲 中 的 数据 按 
照 具 体 的 GPU 的 要 求 组织 一 下 ， 然 后 再 传递 给 GPU。 下 面 我 们 就 以 Intel i915 
系列 GPU 的 Pipeline 中 的 _intel_render_stage 为 例 ， 看 看 其 是 如 何 为 GPU 准 备 
批量 缓冲 的 。 


前 面 我 们 在 函数 _tnl_run_pipeline 中 看 到 ，Pipeline 在 运行 时 ， 是 依次 调 
用 各 个 阶段 的 run 函 数 来 运行 各 个 阶段 的 。_intel_render_stage 阶 段 的 run 函 数 


是 intel run_render: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel render.c: 


01 static GLboolean intel run render(struct gl] context * ctx, ...) 
v2 4 

03 i 

04 for (i = 0; i < VB->PrimitiveCount; i++) { 

05 GLuint prim = tnl translate prim(&VB->Primitivel[il]); 
06 GLuint start = VB->Primitive [II] .start; 

0 GLuint length = VB->Primitivel[lil] .count; 


08 

09 

10 

二 于 } 
12 dm 
13 INTEL FIREVERTICES (intel); 
14 

TB} 


intel render tab verts[prim & PRIM MODE MASK] (ctx, 
start, start + length, prim); 


人 


其 中 ， 代 码 第 4~11 行 的 for 循 环 ， 将 依次 调用 特定 GPU 相关 的 函数 按照 
GPU 要 求 的 格式 重 狐 组 织 顶 点 缓冲 。 以 Intel GPU 的 3D 张 动 为 例 ， 其 另外 分 
配 了 与 驱动 相关 的 顶点 缓冲 存储 重新 组 织 顶 点 数据 : 


Mesa-8.0.3/src/mesa/drivers/dri/intel/intel context.h: 


struct intel context 


{ 
struct 
{ 


drm intel bo *vb bo; 
Uint8 七 *vb; 


} prim; 


在 结构 体 prim 中 ，vb 指 回 的 是 用 户 空间 的 顶点 缓冲 ，vb_bo 指 加 的 是 内 
核 空 间 创建 的 保存 顶点 数据 的 BO 。 


intel i915 系 列 GPU 的 3D 张 动 中 组 织 三 角形 的 顶点 绥 神 的 函数 为 


\ 


intel_draw_triangle: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel tris.c: 


static void intel] draw triangle(struct intel context *intel, 
intelVertexPtr v0O, intelVertexpPtr v1l, intelVertexpPtr v2) 


GLuint vertsize = intel->vertex size; 
GLuint *vb = intel get prim space (intel, 3); 
Tnt 3 


COPY DWORDS (j, vb, vertsize, vO),; 
COPY DWORDS(jJ, vb, vertsize, vi1); 
COPY DWORDS(j, vb, vertsize, v2); 


函数 intel_draw_triangle 使 用 宏 COPY_DWORDS 向 顶点 缓冲 中 指定 偏 移 


处 写 入 顶点 数据 。 对 于 每 一 个 三 角形 来 说 都 包括 三 个 顶点 数据 ， 因 此 调用 
三 次 安 COPY_DWORDS， 将 三 角形 的 三 个 顶点 写 入 了 顶点 缓冲 。 


处 理 完 顶 点 缓冲 后 ， 函 数 intel]_run_render 就 将 开始 为 GPU 组 织 批 量 绥 
冲 。Intel GPU 的 3D 张 动 中 批量 缓冲 的 数据 抽象 如 下 : 


Mesa-8.0.3/src/mesa/drivers/dri/intel/intel context.h: 


struct intel context 


{ 


struct intel batchbuffer { 
drm intel bo *bo; 


Wint32 tt maDlsL192].; 


} batch; 


在 结构 体 intel_batchbuffer 中 ， 数 组 map 束 是 用 户 空 间 中 的 批量 缓冲 ，bo 
指 问 的 就 是 内 核 空间 中 的 保存 批量 数据 的 BO。 可 见 ，3D 了 驱动 中 使 用 批量 绥 
冲 的 方式 与 2D 驱 动 中 的 基本 相同 。 


函数 intel _run_render 在 最 后 调用 了 宏 INTEL_FIREVERTICES， 开 启 了 
批量 缓冲 的 生成 过 程 : 


Mesa-8.0.3/src/mesa/drivers/dri/intel/intel context.h: 


#define INTEL FIREVERTICES (intel) \ 
do { N 
if ((intel)->prim.flush) * 
(intel)->prim.flush (intel),; \ 
} while (0) 


函数 指针 flush 指 回 函 数 intel_flush_prim: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel tris.c: 


01 void intel flush prim(struct intel context *intel) 


02 { 

03 wy 

04 BEGIN BATCH (2+len); 

05 if (cmd) 

06 OUT BATCH( 3DSTATE LOAD STATE IMMEDIATE 1 | cmd | ...)); 
07 if (vb bo != i915->current vb bo) { 

08 OUT RELOC(Vb bo, I915 GEM DOMAIN VERTEX, 0, 0); 
09 i915=>current vb bo = Vb_ bo; 

10 } 

11 RY 

2 OUT_ BATCH( 3DPRIMITIVE | 

13 PRIM INDIRECT | 

14 PRIM INDIRECT SEQUENTIAL | 

15 intel->prim.primitive | 

16 GOUNE): 

J OUT BATCH(offset / (intel->vertex size * 4)); 

18 ADVANCE BATCH(); 

4 2 


20 } 


这 里 ， 我 们 再 次 看 到 与 2D 驱 动 中 类 似 的 宏 定义 (如 OUT_BATCH 
等 ) ， 它 们 基本 与 2D 驱 动 中 的 定义 完全 相同 ， 我 们 不 再 展开 分 析 这 些 宏 定 
义 了 。 在 上 壕 组 织 批量 缓冲 的 代码 片段 中 : 


1) 第 6 行 代码 在 批量 缓冲 中 填充 了 发 给 GPU 的 3D 命 令 的 指令 代码 
(opcode) ; 


2) 第 8 行 代码 在 批量 缓冲 中 填充 了 引用 的 保存 顶点 数据 的 BO; 


3) 第 12~16 行 代码 在 批量 缓 促 中 填写 了 泻 染 原 语 的 相关 信息 ， 比 如 绘 
制 的 是 三 角形 还 是 线段 等 ; 


4) 第 17 行 代码 指明 了 绘制 这 个 原 语 需要 的 顶点 数据 在 保存 顶点 数据 的 
BO 中 的 偏 移 。 


至 此 ， 用 户 空间 中 的 批量 缓冲 也 准备 好 了 。 下 一 步 ， 束 是 将 用 户 空 间 
的 数据 复制 到 内 核 空 间 的 BO， 并 启动 GPU 中 的 Pipeline 。 


5. 复 制 顶 点 数据 和 批量 数据 到 内 核 空间 


在 Pipeline 的 软件 阶段 ， 所 有 阶段 的 计算 结果 都 保存 在 用 户 空间 ， 为 了 
启动 Pipeline 的 硬件 阶段 ， 显 然 需 要 将 这 些 数据 复制 到 内 核 空间 的 BO， 这 样 
GPU 才 可 以 访问 。_mesa flush 最 后 将 调用 3D 驱 动 中 的 函数 
_intel_batchbuffer_flush 进 行 复制 : 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel batchbuffer.c: 


int intel batchbuffer fush(,.,.,) 


{ 


if (intel->vtbl .finish batch) 
intel->vtbl .finish batch(intel); 


ret = do flush locked (intel); 


我 们 先 来 看 一 下 函数 finish_batch。 对 于 i915 来 说 ， 其 指向 的 函数 是 


intel finish_vb: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel tris.c: 


void intel finish vbl(struct intel context *intel) 


{ 


drm intel bo subdata(lintel->prim.vb bo, 0, ...); 


函数 drm_intel_bo_subdata 我 们 已 经 见 过 了 ， 其 将 用 户 空 间 的 顶点 缓冲 
中 的 数据 复制 到 内 核 空间 中 保存 顶点 数据 的 BO 。 


接 下 来 ， 再 来 看 函数 intel batchbuffer flush 中 调用 的 do_flush_locked: 


Mesa-8.0.3/src/mesa/drivers/dri/i915/intel batchbuffer.c: 


static int do flush locked(struct intel context *intel) 


ret = drm intel bo subdata(batch->bo, 0; 4*batch->used, ...); 


ret = drm intel bo mrb exec(...); 


函数 do_flush_locked 首 先 调用 drm_intel bo_subdata 将 用 户 空 间 的 批量 组 
冲 中 的 数据 复制 到 内 核 空 间 中 保存 批量 数据 的 BO。 至 此 ， 用 户 空间 的 顶点 
缓冲 和 批量 缓冲 中 的 数据 都 被 复制 到 内 核 空间 的 BO。 


在 将 用 户 空 间 的 数据 复制 到 内 核 空间 中 的 BO 后 ，do_flush_locked 调 用 
库 libdrm 中 的 函数 drm_intel_bo_mrb_exec 通 知 GPU 启 动 其 Pipeline 开 始 泻 
个 过 程 我 们 下 一 局 讨 论 。 
6. 启 动 GPU 中 的 Pipeline 
将 数据 复制 到 内 核 空间 的 BO 后 ， 接 下 来 就 需要 通知 GPU 来 读 取 这 些 数 
据 ， 并 执行 GPU 中 的 Pipeline。 以 Intel GPU 为 例 ， 其 规定 需要 将 批量 数据 组 


织 到 一 个 环形 缓冲 区 中 ， 然 后 GPU 从 环形 缓冲 区 中 读 取 并 执行 命令 ， 如 图 8- 
9 所 示 。 


Head 一 -一 了 ead Offset 
Command 
Batch buffer | Beh Buffer Start _3D cmds ， cmds ， 
Be 中 二 Eee | Command Parser 
: eo, 
人 pr Tail Offset Display Engine 


Ring Buffer BO GPU 


图 8-9 GPU 命令 流 


环形 缓冲 区 也 只 是 从 内 存 中 分 配 的 一 块 用 于 显存 的 普通 存储 区 ， 所 
以 ， 当 内 核 中 的 DRM 模 块 组 织 好 其 中 的 数据 后 ，GPU 并 不 会 目 动 到 环形 缓 
冲 区 中 读 取 数据 ， 而 是 需要 通知 GPU 来 读 取 。 


那么 内 核 如 何 通知 GPU 呢 ? 熟悉 驱动 开发 的 读者 应 该 比较 容易 猜 到 ， 
方法 之 一 就 是 直接 写 GPU 的 寄存 器 。Intel GPU 为 环形 缓冲 区 设计 了 专门 的 
寄存 器 ， 典 型 的 包括 Head Offset、Tail Offset 等 。 其 中 寄存 器 Head Offset 中 
记录 环形 缓存 区 中 有 效 数 据 的 起 始 位 置 ， 寄 存 器 Tail Offset 中 记录 的 则 是 环 
形 缓存 区 中 有 效 数据 的 结束 位 置 。 


一 旦 内 核 中 的 DRM 模 块 向 寄存 器 Tail Offset 中 写 入 数据 ，GPU 就 将 对 比 
寄存 硕 Head Offset 和 Tail Offset 中 的 值 。 如 果 这 两 个 寄存 器 中 的 值 不 相等 ， 
那么 就 说 明 环 形 缓冲 区 中 已 经 存在 有 效 的 命令 了 ，GPU 中 的 命令 解析 单元 

(Command Parser) 通过 DMA 的 方式 直接 从 环形 缓冲 区 中 读 取 命令 ， 并 根 
据 命令 的 类 型 ， 定 向 给 不 同 的 处 理 引 擎 。 如 果 是 3D 命 令 ， 则 转发 给 GPU 中 
的 3D 引 警 ， 如果 是 2D 命 令 ， 则 转发 给 GPU 中 的 BLT 引 警 ; 如果 是 控制 显示 
的 ， 则 转发 给 Display 引 擎 ， 等 等 。 


理解 了 相关 原理 后 ， 下 面 我 们 就 来 看 看 DRM 中 具体 的 实现 。 在 函数 
drm_intel bo_subdata 将 数据 复制 到 内 核 空间 的 BO 后 ，do_flush_locked 调 用 
函 数 drm_intel_bo_mrb_exec 癌 内 核 DRM 模 块 发 送 命 令 
DRM_IOCTL 1915_GEM_EXECBUFFER 或 者 
DRM_IOCTL 1I915_GEM_EXECBUFFER2 (依据 GPU 的 具体 情况 ) 。 以 


DRM 模 块 中 处 理 命 令 DRM_IOCTL 1915 GEM_EXECBUFFER2 的 函数 
i915_gem_execbuffer2 为 例 ， 组 织 并 启动 GPU 读 取 环形 缓冲 区 的 相关 代码 如 
下 : 


linux-3.7.4/drivers/gpu/drm/i915/i915 gem execbuffer.c: 


int i915 gem execbuffer2(...) 


{ 


ret = i915 gem do execbuffer(...); 


} 


static int i915 gem do execbuffer(...) 


{ 

ret = ring->dispatch execbuffer(ring, ...); 
} 
linux-3.7.4/drivers/gpu/drm/i915/intel ringbuffer.c: 


static int i915 dispatch execbuffer(...) 


{ 


intel ring emit (ring, MI BATCH BUFFER START | MI _ BATCH GTT); 
intel ring emit (ring, offset | MI BATCH NON SECURE); 
intel ring advance (zing) ; 


注意 函数 i915_dispatch_execbuffer 中 的 函数 intel_ring_emit， 读 者 一 定 想 
到 了 组 织 批 量 缓 冲 的 宏 OUT_BATCH 的 定义 ， 没 错 ， 这 里 就 是 在 填充 环形 绥 
冲 区 。 


在 组 织 好 环形 缓冲 后 ，i915_dispatch_execbuffer 调 用 了 函数 
intel_ring_advance 扣 动 了 GPU 的 扳机 ， 相 关 代 码 如 下 : 


linux-3.7.4/drivers/gpu/drm/i915/intel ringbuffer.c: 


void intel ring advance(struct intel ring buffer *ring) 


{ 


ring->write tail(ring, ring->tail),; 


static void ring write taill(struct intel ring buffer *ring, 
u32 value) 


I915 WRITE TAIL(ring, value); 


} 


linux-3.7.4/drivers/gpu/drm/i915/intel ringbuffer.h: 


#define I915 WRITE TAIL (ring, val) \ 
I915 WRITE (RING TAIL( (ring)->mmio base), val) 


以 i915 系 列 为 例 ，GPU 的 相应 寄存 器 在 CPU 地 址 空间 中 占据 的 地 址 如 
下 : 


linux-3.7.4/drivers/gpu/drm/i915/i915 reg.h: 


#define RENDER RING BASE 0x02000 
#define RING TAIL (base) ( (base) +0x30) 
#define RING HEAD (base) ( (base)+0x34) 


根据 mtel] 的 GPU 的 手册 ， 地 址 "0x02000+0x30" 恰 恰 就 是 GPU 的 寄存 器 
Tail Offset 在 CPU 的 地 址 空间 中 分 配 的 地 址 。 


根据 上 述 分 析 可 见 ， 内 核 的 DRM 模 块 通过 写 GPU 的 寄存 器 Tail Offset 局 
动 了 GPU 中 的 Pipeline。 最 后 Pipeline 会 将 生成 的 图 像 的 像素 阵列 输出 到 后 组 
冲 的 BO。 


8.4.3 ”交换 前 缓冲 和 后 缓冲 


应 用 程序 绘制 完成 后 ， 需 要 将 后 缓冲 交换 (swap) 到 前 缓冲 ， 其 中 有 
三 个 问题 需要 考虑 。 


(1) 谁 来 负责 交换 


如 采 应 用 目 己 负 贡 将 后 缓冲 更 新 到 前 缓冲 ， 那 么 当 有 多 个 应 用 同时 更 
新 前 缓冲 时 如 何 协调 ?” 显然 将 交换 动作 交 给 更 擅长 窗口 管理 的 X 服 务 如 统 一 
协调 更 为 合理 。 


如 果 X 服 务 器 开局 了 复合 扩展 ， 更 需要 知道 应 用 已 经 更 新 前 缓冲 了 ， 因 
为 X 服 务 器 需要 通知 复合 管理 器 重新 合成 前 缓冲 。 


综 上 ， 应 该 由 X 服 务 万 来 负责 交换 前 后 缓冲 。 


对 于 GPU 支持 交换 的 情况 ，X 服 务 器 通过 2D 张 动 请 求 GPU 进行 交换 。 
否则 X 服 务 器 只 能 将 前 缓冲 和 后 缓冲 的 BO 映射 到 用 户 空间 ， 使 用 CPU 逐 位 
复制 。 


(2) 交换 的 时 机 


与 2D 应 用 不 同 ，3D 程 序 通常 涉及 复杂 的 动画 和 图 像 ， 如 果 显 示 控 制 需 
正在 扫描 前 缓冲 的 同时 ，X 服 务 硕 更 新 了 前 缓冲 ， 那 么 可 能 会 导致 屏 医 出 现 
撕 裂 (tearing) 现象 。 所 谓 的 撕 裂 就 是 指 本 应 该 分 为 两 桢 显示 在 屏幕 上 的 图 


像 同 时 显示 在 屏幕 上 ， 上 半 部 分 是 一 帧 的 上 半 部 分 ， 而 下 半 部 分 是 另外 一 
帧 的 下 半 部 分 ， 情 况 严 重 的 将 导致 屏幕 出 现 内 烁 (flicker) 


以 一 个 刷新 率 为 60Hz 的 显示 器 为 例 ， 显 示 控制 器 每 隔 1/60 秒 从 前 缓冲 
读 取 数 据 传 给 显示 器 。 每 开始 新 的 一 帧 扫描 时 ， 显 示 控 制 器 都 从 前 缓冲 的 
最 左上 角 的 点 ， 即 第 一 行 的 第 一 个 点 开始 ， 逐 行进 行 扫描 ， 直 到 扫描 到 图 
像 右 下 角 的 点 ， 即 最 后 一 行 的 最 后 一 个 点 。 经 过 这 样 一 个 过 程 之 后 ， 就 完 
成 了 一 帧 图 像 的 扫描 。 然 后 显示 控制 器 回溯 (retrace) 到 第 一 行 的 第 一 个 点 
的 位 置 ， 等 待 下 一 帧 扫描 开始 ， 如 图 8-10 所 示 。 
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图 8-10 ”图像 扫描 示意 图 


更 新 一 帧 图 像 远 不 需要 1/60 秒 ， 从 更 新 完 最 后 一 行 的 最 右 侧 一 个 点 ， 到 
开始 扫描 下 一 帧 之 间 的 间 除 被 称 为 垂直 空 亲 (vertical blank) ， 简 称 


为 "vblank"。 显 然 ， 如 果 在 vblank 这 段 时 间 更 新 前 缓冲 ， 束 不 会 导致 上 述 撕 
裂 和 闪烁 现象 的 出 现 了 。 


(3) 交换 的 方法 


交换 后 缓冲 和 前 缓冲 通常 有 两 种 方法 ; 第 一 是 复制 ， 在 绘制 完成 后 ，X 
服务 句 将 后 缓冲 中 的 数据 复制 到 前 缓冲 ， 如 图 8-11 所 示 。 
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Back Buffer : | 


Back Buffer 


图 8-11 复制 模式 


但 是 这 种 方法 效率 相对 较 低 ， 所 以 开发 者 们 设计 了 页 翻转 模式 (page 
flip) 。 页 翻转 模式 不 进行 数据 复制 ， 而 是 将 显示 控制 器 指向 后 缓冲 。 后 绥 
冲 与 前 缓冲 的 角色 进行 互 换 ， 后 缓冲 播 身 一 变 成 为 前 缓冲 ， 显 示 控 制 磊 将 
扫描 后 缓冲 的 数据 到 屏幕 ， 而 原来 的 前 缓冲 则 变 成 了 后 缓冲 ， 应 用 程序 在 
前 缓冲 上 进行 绘制 ， 如 图 8-12 所 示 。 


Front Buffer | Back Buffer 
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| Buffer a W F : Flip : Buffer a 
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图 8-12 页 翻转 模式 


页 翻转 模式 虽然 效率 高 ， 但 也 不 是 所 有 的 情况 都 适用 。 典 型 的 ， 当 一 
个 应 用 处 于 全 屏 模 式 时 ， 可 以 采用 页 翻转 模式 互 换 前 缓冲 和 后 缓冲 。 但 是 
这 对 于 使 用 复合 管理 器 的 图 形 系 统 来 说 ， 其 实 已 经 大 大 的 提升 效率 了 ， 因 
为 复合 管理 器 控制 看 整个 屏幕 的 显示 ， 所 以 复合 管理 器 可 以 使 用 页 翻转 模 
式 交换 前 缓冲 和 后 缓冲 。 


1. 应 用 发 送 交 换 请 求 


对 于 一 个 OpenGL 程 序 来 说 ， 在 绘制 完成 后 ， 需 要 调用 GLX 扩 展 中 的 画 
数 glXSwapBuffers 向 X 服 务 器 发 出 交换 请 求 : 


Mesa-8.0.3/src/glx/glxcmds .c: 


_X EXPORT void glXSwapBuffers(Display * dpy, GLXDrawable drawable) 


{ 


glFlush(); 


(*pdraw->psc->driScreen->swapBuffers) (pdraw, 0, 0, 0); 


glXSwapBuffers 首 和 完 调用 glFlush 启 动 Pipeline 进 行 渲 染 。 然 后 调用 DRI2 
扩展 的 指 秆 swapBuffers 指 向 的 函数 向 XX 服务 器 发 出 交换 请 求 。DRI2 扩 展 中 
指针 swapBuffers 指 加 的 函数 是 DRI2SwapBuffers: 


Mesa-8.0.3/src/glx/dri2.c: 


void DRI2SwapBuffers(...) 


{ 


GetReq (DRI2SwapBuffers, req); 


req->reqType = info->codes->major opcode; 
req->dri2ReqType = X DRI2SwapBuffers; 
req->drawable = drawable,; 


load swap reql(lreq, target msc, divisor, remainder); 


XReply (dpy, (xReply *)&rep, 0, xFalse); 


函数 DRI2SwapBnuffers 创 建 了 一 个 类 型 为 X_DRI2SwapBuffers 的 X 请 求 ， 
然后 调用 函数 _XReply 将 这 个 请 求 发 送 给 X 服 务 右 。 


2.X 服 务 铝 处理 交换 请 求 


服务 絮 中 人 处理 来 和 目 OpenGL 应 用 的 请 求 在 DRVGLX 的 扩展 模块 中 ， 对 
应 的 函数 是 DRI2SwapBuffers: 


Xorg-server-1.12.2/hw/xfree86/dri2/dri2.c: 


int DRI2SwapBuffers(...) 


{ 


for (i = 0; i < pPriv->bufferCount; i++) { 
if (pPriv->buffers[i]->attachment == DRI2BufferFrontLeft) 
pDestBuffer = (DRI2BufferPptr) pPriv->buffers([i],; 
if (pPriv->buffers[i]->attachment == DRI2BufferBackLeft) 
pSrcBuffer = (DRI2BufferPtr) pPriv->buffers [i],; 
} 
ret = (*ds->ScheduleSwap) (client, pDraw, pDestBPuffer, 


pSrcBuffer, swap target, divisor, remainder, func, data); 


函数 DRI2SwapBuffers 首 先 获取 请 求 更 新 的 窗口 的 前 缓冲 和 后 缓冲 。X 
服务 絮 在 前 面 创建 帧 绥 冲 时 已 经 将 各 个 缓冲 记录 到 了 各 个 窗口 中 ， 所 以 这 


里 取出 即 可 。 其 中 ， ee pSrcBuffer 指 疝 后 缓冲。 取得 
前 缓冲 和 后 缓冲 后 ， 有 具体 的 交换 动作 显然 需要 2D 张 动 来 完成 。 
DRI2SwapBuffers 调 用 2D 张 动 中 的 函数 ScheduleSwap 交 换 后 缓冲 和 前 缓冲 。 


在 Intel GPU 的 2D 驱 动 中 ， 函 数 指针 ScheduleSwap 指 癌 范 数 
1830DRI2ScheduleSwap: 


xf86-video-intel-2.19.0/src/intel dri.c: 


01 static int I830DRI2ScheduleSwap(...) 


| 

03 A 

04 drmVvBlank vbl; 

05 Rk 

06 DRI2FrameEventPtr swap_ info = NULL.; 

oF enum DRI2FrameEventType swap type = DRI2 _ SWAP; 
08 ei 

09 if (can exchange (draw, front, back)) { 

10 Swap type = DRI2 FLIP; 

a flip = 1; 

po } 

be 

14 swap_info->type = swap_type; 

ES 人 

16 vbl.request.signal = (unsigned long)swap info; 
D7 ret = drmWaitVvBlank (intel->drmSubFD, &Vvb]l1); 

18 

19 } 


前 面谈 到 X 服 务 器 应 该 在 vblank 时 更 新 前 缓冲 ， 实 现 中 也 确实 如 此 。 
I830DRI2ScheduleSwap 没 有 直接 进行 交换 ， 而 是 调用 库 libdrm 中 的 函数 
drmwaitVBlank， 这 个 函数 告诉 显示 控制 问 ， 在 vblank 时 ， 回 内 核发 送 
vblank 事 件 ， 如 第 17 行 代码 所 示 。 


辑 数 1830DRI2ScheduleSwap 需 要 做 的 男 外 一 件 事 束 是 判断 前 缓冲 和 后 
缓冲 的 交换 方式 。 默 认 的 交换 方式 是 复制 ， 如 第 7 行 代码 所 示 。 第 9~12 行 代 
码 调用 函数 can_exchange 来 判断 是 否 可 以 使 用 更 高 效 的 页 翻转 方式 。 


Intel GPU 的 2D 张 动 在 初始 化 时 注册 vblank 事 件 的 回调 函数 是 


intel vblank_handler: 


xf86-video-intel-2.19.0/src/intel display.c: 


static void intel vblank handler(...) 


{ 
} 


I830DRI2FrameEventHandler (frame, tv sec, tv usec, event); 


xf86-video-intel-2.19.0/src/intel dri.c: 


void I830DRI2FrameEventHandler(..., DRI2FrameEventPptr swap_info) 


{ 


switch (swap info->type) { 
case DRI2 FLIP: 
/* If we can still flip... */ 
if (can exchange (drawable, swap info->front, 
swap_info->back) && 
I830DRI2ScheduleFlipl(intel, drawable, swap_info)) 
return; 


/* else fall through to exchange/blit */ 
case DRI2 SWAP: { 


I830DRI2CopyRegion (drawable, &region, swap info->front, 
swap_info->back); 


收 到 vblank 事 件 后 ， 函 数 1830DRI2FrameEventHandler 首 先 判 断 等 竺 
vblank 的 交换 请 求 硕 望 使 用 的 是 页 翻转 模式 还 是 复制 模式 。 如 有 果 是 页 翻转 模 
式 ， 为 了 安全 起 见 ， 再 次 使 用 函数 can_exchange 检 查 是 否 可 以 进行 页 翻转 ， 
确认 没有 问题 后 ， 则 调用 画 数 1830DRI2ScheduleFlip 执 行 翻转 。 和 否则 ， 则 调 
用 函数 1830DRI2CopyRegion 将 后 缓冲 的 内 容 复 制 到 前 绥 冲 。 


(1) 页 翻转 模式 
进行 页 翻转 的 函数 1830DRI2ScheduleFlip 的 相关 代码 如 下 : 


xf86-video-intel-2.19.0/src/intel dri.c: 


static Bool I830DRI2ScheduleFlip(...) 


( 
if (!intel do pageflip(intel, ...)) 


I830DRI2ExchangeBuffers (intel, info->front, info->back); 


I830DRI2ScheduleFlip 调 用 2D 张 动 中 的 函数 intel do_pageflip 进 行 翻转 。 
当然 翻转 后 需要 更 新 状态 ， 包 括 更 新 当 Screen Pixmap 对 应 的 BO， 这 就 是 多 
数 1830DRI2ScheduleFlip 调 用 1830DRI2ExchangeBuffers 的 目的 。2D 了 驱动 中 
数 intel_do_pageflip 的 代码 如 下 : 


加 车 


xf86-video-intel-2.19.0/src/intel display.c: 


Bool intel do pageflip(...) 


{ 


if (drmModePageFlip(...)) { 


函数 intel do_pageflip 并 没有 使 用 库 libdrm 提 供 的 接口 ， 如 
drmModeSetCrtc 设 置 显示 控制 器 扫描 的 缓冲 ， 而 是 使 用 了 接口 
drmModePageFlip。 相 比 于 有 点 莽撞 的 drmModeSetCrtc， 画 数 
drmModePageFlip 能 确保 是 在 发 生 vblank 时 设置 显示 控制 器 扫描 的 缓冲 。 
drmModePageFlip 将 翻转 的 动作 排队 到 下 一 个 vblank 事 件 发 生 时 的 处 理 队 列 
中 ， 在 下 个 vblank 发 生 时 ， 设 置 显示 控制 器 扫描 的 缓冲 。 


(2) 复制 模式 


处 理 复制 模式 的 函数 1830DRI2CopyRegion 的 代码 如 下 : 


xf86-video-intel-2.19.0/src/intel dri.c: 


static void I830DRI2CopyRegion(DrawablePtr drawable, ...) 


{ 


gc->ops->CopyAreal(lsrc, dst, gc, ...); 


看 到 ops， 读 者 一 定 非 常熟 悉 了 ， 没 错 ， 这 就 是 我 们 前 面 讨 论 2D 泻 染 时 
提 及 的 画笔 。 在 UXA (uxa_ops) 中 ，CopyArea 对 应 的 函数 是 
intel_uxa_copy: 


xf86-video-intel-2.19.0/src/intel uxa.c: 


01 static void intel. Uxa Copy\(,.s) 


02 1 

03 & 

04 { 

05 BEGIN BATCH BLT(8); 

06 

07 cmd = XY SRC COPY BLT CMD; 

08 a 

09 OUT_BATCH (cmd); 

10 

Ii OUT BATCH(intel->BR[13] | dst pitch); 

了 OUT BATCH((dst yl << 16) | (dst xl & Oxffff)); 
13 OUT PATCH( (dst Y2 < 165) | (dat x2 E (UxELEE))S 
14 OUT RELOC PIXMAP FENCED (dest, ...); 

15 OUT BATCH( (src yl << 16) | (BEG XL EC OKEEEE))%s 
16 OUT BATCH (src pitch); 

137 OUT RELOC PIXMAP FENCED (intel->render source, ...); 
18 

19 ADVANCE BATCH(); 

20 } 

> 


看 到 函数 intel_uxa_copy 的 内 容 是 否 似曾相识 ? 没 错 ， 指 令 


XY_SRC_COPY_BLT 与 8.3.2 节 讨论 的 指令 XY_COLOR_BLT 非 常 相似 ， 


大 的 不 同 是 多 了 复制 的 源 的 信息 。Intel GPU 的 指令 XY_SRC_COPY_BLT 的 
格式 如 表 8-2 所 示 。 


表 8-2 Intel GPU 指令 XY_SRC_COPY_BLT 的 格式 


目标 区 域 基 址 
31:16 源 区 域 顶 部 坐标 ( Y1 ) 
15:00 源 区 域 左 侧 坐标 ( X1 ) 
31:16 保留 
15:00 源 区 域 图 像 跨 度 
7=BRIS 31:00 源 区 域 基 址 


双 字 (寄存 器 ) 描述 

1=BR13 15:00 目标 图 像 跨度 

31:16 目标 区 域 顶部 坐标 (Y1 ) 
2 = BR22 

15:00 目标 区 域 左 侧 坐 标 (XX1 ) 

31:16 目标 区 域 底部 坐标 ( Y2 ) 
3 = BR23 i 3 

15:00 目标 区 域 右 侧 坐标 ( X2 ) 
4= BRO9 31:00 


下 面 我 们 结合 表 8-2 来 分 析 函 数 intel_uxa_copy 为 GPU 组 织 批 量 缓 冲 的 过 
程 。 


1) 第 9 行 代 码 填充 的 是 第 0 个 双 字 ， 即 BLT3 引 警 的 寄存 器 BR00。 这 个 寄 
存 器 中 最 重要 的 就 是 指令 的 操作 人 码 (Opcode) ， 即 第 22~28 位 。 对 于 指令 
XY_SRC_COPY_BLT， 其 操作 码 是 0x53。 观 察 宏 


XY_SRC_COPY_BLT_CMD 的 定义 : 


xf86-video-intel-2.19.0/src/i830 reg.h: 


#define XY SRC COPY BLT CMD ((2<<29) | (0x53<<22) | 6) 


其 中 从 第 22 位 开始 的 0x53 正 是 指令 XY_SRC_COPY _BLT 的 指令 码 。 另 


外 ， 第 29~30 位 设置 为 >， 告诉 GPU 这 个 指令 是 一 个 2D 指 令 ， 需 要 GPU 定向 


给 BLT 引 擎 。 


2) 第 11 行 代码 填充 的 是 第 1 个 双 字 ， 对 应 BLT 引 擎 的 寄存 器 BR13， 其 
中 "intel- >BR[13]" 在 8.3.2 节 我 们 已 经 讨论 过 ， 表 示 色 深 。 另 外 ，dst_pitch 表 
示 目 标 区 域 的 跨度 ， 所 谓 的 跨度 就 是 以 字 节 为 单位 的 图 形 的 宽度 。 


3) 第 12 行 代码 填充 了 第 2 个 双 字 ， 对 应 BLT3| 警 的 寄存 器 BR22， 这 个 
寄存 器 中 保存 的 是 目标 区 域 的 左上 和 角 的 坐标 。 


4) 第 13 行 代码 填充 了 第 3 个 双 字 ， 对 应 BLT3 引 警 的 寄存 器 BR23， 这 个 
寄存 器 中 保存 的 是 目标 区 域 的 右 下 角 的 坐标 。 


5) 第 14 行 代码 填充 了 第 4 个 双 字 ， 对 应 BLT 引 擎 的 寄存 器 BR09， 这 个 
寄存 器 中 保存 的 是 存储 目标 区 域 像素 阵列 的 BO， 当 然 使 用 的 是 BO 在 GPU 虚 
拟 地 址 空间 的 地 址 ， 即 BO 的 offset。 


6) 第 15 行 代码 填充 了 第 5 个 双 字 ， 对 应 BLT3| 擎 的 寄存 器 BR26， 这 个 
寄存 器 中 保存 的 是 源 区域 的 左上 和 角 的 坐标 。 


7) 第 16 行 代码 填充 了 第 6 个 双 字 ， 对 应 BLT3 引 警 的 寄存 器 BR11， 这 个 
寄存 器 中 保存 的 是 源 区 域 的 图 形 的 跨度 。 


8) 第 17 行 代码 填充 了 第 7 个 双 字 ， 对 应 BLT 引 警 的 寄存 器 BR12， 这 个 
寄存 器 中 保存 的 是 存储 源 区 域 的 像素 阵列 的 BO 的 地 址 。 


8.5 Wayland 


将 所 有 图 形 全 部 交 由 X 服 务 器 绘制 的 这 种 设计 ， 在 以 2D 应 用 为 主 的 时 
代 ， 一切 还 相安 无 事 。 但 是 随 着 基于 3D 的 应 用 越 来 越 多 ， 效 率 问题 逐渐 凸 
显 出 来 。 与 2D 程 序 不 同 ，3D 程 序 的 数据 量 要 大 得 多 ， 所 以 应 用 与 又 服务 器 
之 间 需 要 传递 大 量 的 数据 。 设 想 一 下 几 个 人 过 独木桥 和 万 人 争 过 独木桥 的 
场景 ， 显 然 ，X 曾 经 引 以 为 傲 的 设计 一 一 通过 网 络 通信 的 客 刻 / 服 务 右 架 
构 ， 成 为 性 能 的 瓶 倾 。 


为 了 解决 这 个 问题 ，X 的 开发 者 们 设计 了 DRI 机 制 ， 即 应 用 程序 不 再 将 
绘制 图 形 的 请 求 发 送 给 X 服 务 器 ， 而 是 由 应 用 程序 自行 绘制 。 这 种 设计 与 又 
最 初 的 设计 原则 虽然 有 些 格格 不 入 ， 但 是 从 某 种 程度 上 确实 缓解 了 3D 应 用 
的 效率 问题 。 


但 是 ， 好 景 不 长 ， 人 们 逐渐 不 再 满足 于 看 上 去 比较 “有 条 板 ” 的 图 形 用 户 
界面 ， 人 们 退 求 具有 更 华丽 的 3D 特 效 的 图 形 用 户 界 面 ， 比 如 窗口 弹出 和 关 
闭 时 的 放大 /缩小 动画 、 窗 口 之 间 的 透明 等 。 于 十 开发 者 们 为 xX 设计 了 复合 
(Composite) 扩展 ， 并 仿效 窗口 管理 器 设计 了 一 个 所 谓 的 复合 管理 器 
(Composite Manager) 来 实现 这 些 效果 。 


我 们 以 2D 绘 制 过 程 为 例 来 简要 地 看 一 下 什么 是 复合 扩展 以 及 复合 管理 
器 ， 如 图 8-13 所 示 。 
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图 8-13 复合 扩展 


开局 复合 扩展 后 ， 最 大 的 一 个 区 别 是 所 有 的 窗口 都 不 再 共 至 一 个 前 绥 
冲 ， 而 是 有 了 各 目的 离 屏 区 域 。X 服 务 右 在 各 个 窗口 的 离 屏 区 域 上 进行 给 
制 。 在 绘制 好 后 ，X 服 务 器 向 另外 一 个 特殊 的 应 用 复合 管理 器 (Composite 
Manager) 发 出 Damage 通 知 。 然 后 由 复合 管理 器 请 求 X 服 务 器 对 这 些 离 屏 的 
窗口 的 缓 促 区 进行 合成 ， 最 后 请 求 X 服 务 右 显示 到 前 绥 冲 。 


下 面 的 代码 片段 展示 了 复合 管理 为 窗口 创建 离 屏 缓冲 的 过 程 : 


xorg-server-1.12.2/composite/compinit.c: 


Bool compScreenInit (ScreenPtr pScreen,) 


pScreen->CreateWindow = compCreateWindow; 
XOorg-server-1.12.2/composite/compwindow.c: 


Bool compCreateWindow (WindowPtr pWin) 


{ 


compRedirectWindow( ... ); 


我 们 看 到 ， 在 开局 复合 扩展 后 ， 屏 幕 中 的 指针 CreateWindow 已 经 指 问 
了 复合 扩展 中 实现 的 函数 compCreatewWindow。 而 在 画 数 compCreateWindow 
中 ， 其 使 用 了 芳 数 compRedirectWindow 将 窗口 从 前 缓冲 重 定 癌 到 一 个 离 屏 区 
域 。 


在 这 个 复合 过 程 中 ， 就 是 制造 那些 绚丽 效果 的 地 方 。 比 如 在 合成 的 过 
程 中 ， 我 们 使 用 如 图 8-14 的 方法 ， 就 可 以 使 窗口 看 起 来 是 以 放大 效果 出 现 
的 。 
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图 8-14 ”以 放大 效果 出 现 的 窗口 


使 用 复合 管理 后 ， 绚 丽 的 效果 有 了 ， 但 是 仔细 观察 图 8-13 会 发 现 ，X 补 
人 诉 病 的 基于 网 络 通信 的 客户 /服务 器 模式 的 问题 又 变 得 严重 了 。 除 了 X 服 
务 器 和 应 用 之 间 的 通信 外 ， 为 了 进行 合成 ，X 服 务 器 和 复合 管理 器 之 间 又 多 
了 一 层 通信 关系 。 


事实 上 ， 在 DRI 的 演进 过 程 中 ，X 不 断 被 拆 分 和 瘦身 ， 开 发 者 从 X 中 移 
除了 大 量 与 泻 染 有 关 的 功能 到 内 核 和 各 种 程序 库 中 。 慢 慢 的 ， 人 们 发 现 ，X 
所 做 的 事情 已 经 大 为 减少 ， 替 代 X 已 经 不 是 一 项 不 可 能 的 任务 。 于 是 一 部 分 
开发 者 开始 党 试 为 Linux 开 发 替代 X 的 窗口 系统 ，Kristian Hggsberg 提 出 了 
Wayland。 事 实 上 ， 这 一 个 过 程 迟 早 要 发 生 的 ， 即 使 不 是 Wayland， 也 会 清 
现 出 如 Yayland、Zayland 等 。 


Wayland 并 不 是 一 个 全 新 的 事物 ， 它 是 站 在 X 这 个 巨人 的 肩膀 上 ， 在 X 
的 不 断 演 进 中 进化 而 来 的 。 虽 然 从 名 字 上 看 ，Wayland 与 X 没 有 丝 坚 相干 ， 


但 是 实际 上 两 者 的 联系 可 谓 干 丝 万 缕 。Wayland 的 开发 者 Kristian Hagsberg 曾 
经 是 X 的 DRI 的 主要 开发 者 之 一 。 套 用 一 名 奔驰 的 广告 语 ,经典 是 对 经 典 的 
继承 ， 经 典 是 对 经 典 的 背叛 >”，Wayland 去 掉 了 X 的 客户 /服务 器 架构 ， 但 是 
继承 了 X 为 提高 绘制 效率 不 懈 努 力 的 成 果 : DRI。 除 了 逻辑 上 设计 上 不 同 
外 ，Wayland 基 本 的 演 染 原理 与 我 们 前 面 讨 论 的 2D 和 3D 的 演 染 原理 完全 相 
同 。 基 本 上 ， 基 于 Wayland 的 图 形 染 构 如 图 8-15 所 示 。 
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图 8-15 ” Wayland 体系 染 构 


Wayland 本 身 是 一 个 协议 ， 其 具体 的 实现 包括 一 个 合成 器 
(Compositor) 以 及 一 套 协议 实现 库 。 当 然 ， 图 形 库 为 了 与 合成 器 进行 通 
信 ， 在 图 形 库 中 需要 加 入 Wayland 协 议 的 相关 模块 ， 也 就 是 图 8-15 中 的 
Wayland backend 部 分 ， 当 然 这些 都 可 以 基于 Wayland 提 供 的 库 ， 而 不 必 从 头 
再 将 wayland 协 议 实 现 一 遍 。 


在 Wayland 下 ， 所 有 的 图 形 绘制 完全 由 应 用 目 己 负责 。 其 绘制 过 程 与 我 
们 前 面 讨论 的 2D 和 3D 的 绘制 过 程 完全 相同 ， 只 不 过 2D 的 绘制 部 分 也 搬 到 图 
形 库 中 了 ， 绘 制 动 作 与 合成 器 没有 丝毫 关系 。 而 在 绘制 后 ， 应 用 将 前 缓冲 
和 后 缓冲 进行 对 调 ， 并 向 合成 器 发 送 Damage 通 知 ， 当 然 颜色 缓冲 不 一 定 是 
前 后 两 个 ， 在 具体 实现 中 ， 有 的 图 形 系统 可 能 使 用 3 个 、4 个 甚至 更 多 。 在 
收 天 Damage 通 知 后 ， 合 成 右 将 应 用 的 前 绥 促 合成 到 目 己 的 后 缓冲 中 。 而 合 
成 器 的 这 个 合成 过 程 ， 与 普通 应 用 的 绘制 过 程 并 无 本 质 区 别 ， 也 是 通过 图 
形 库 完成 。 


在 合成 完成 后 ， 合 成 右 对 调 后 缓冲 与 前 缓冲 ， 并 设置 显示 控制 部 指 回 
新 的 前 绥 冲 ， 即 原来 的 后 缓冲 。 此 前 的 前 缓冲 作为 新 的 后 绥 冲 ， 并 作为 合 
成 器 下 一 次 合成 的 现场 ， 而 原来 的 后 缓冲 则 变 成 现在 的 前 缓冲 ， 用 于 显示 
控制 右 的 扫描 输出 。 


光盘 下 载 地 址 : http://pan.baidu.com/s/106p43O2 


